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ABSTRACT:  Simulation  interfaces  to  Command,  Control,  Communications,  Computers,  Intelligence, 
Security,  and  Reconnaissance  (C4ISR)  systems  are  essential  to  support:  Simulation  Based  Acquisition 
(SBA);  the  development  of  Doctrine,  Tactics,  Techniques,  and  Procedures  (DTTP);  “Train  as  you  fight;  ” 
Embedded  Training  (both  individual  and  collective);  Course  of  Action  Development  and  Analysis; 
Mission  Planning  and  Rehearsal;  and  Execution  Monitoring.  Modeling  and  Simulation  (M&S)  systems 
have  standardized  on  certain  protocols  and  architectures  for  interoperability,  such  as  the  High  Level 
Architecture  (HLA).  Within  the  Department  of  Defense  (DoD),  the  C4ISR  community  is  also  moving  to 
standardize  on  the  Joint  Technical  Architecture  (JTA)  and  the  Defense  Information  Infrastructure 
Common  Operating  Environment  (DII  COE).  These  interoperability  efforts,  as  well  as  efforts  within  the 
DoD  and  the  international  community  to  standardize  message  formats  and  develop  common  M&S  and 
C4I  data  models  may  -  if  the  appropriate  standards  are  identified  and  developed  -  significantly  enhance 
efforts  to  link  M&S  and  C4ISR  systems.  However,  a  robust  “two-way  ”  dialog  is  required. 

In  order  to  assess  “where  we  are  and  where  we  need  to  so”  the  Simulation  Interoperability  Standards 
Organization  (SISO)  charted  an  M&S-to-Command,  Control,  Communications,  and  Intelligence  (C4I) 
Interoperability  Study  Group  to:  1)  provide  background  and  current  information  on  C4ISR  and 
simulation  interoperability  efforts;  2)  provide  a  standcirds-based  assessment  of  past  and  current 
interoperability  efforts;  and  3 )  make  recommendations  on  how  the  Simulations  Interoperability  Workshop 
(SIW)  C4I  Forum  should  proceed  with  standards  development  activities.  This  paper  is  the  report  of  the 
M&S-to-C4I  Interoperability  SG.  It  discusses  “where  we  have  been,  ”  “where  are  we  now,  ”  “where  we 
should  go,  ”  and  “how  do  we  get  there.  ”  While  the  authors  have  collated  submissions  and  edited  this 
report,  in  truth  it  is  the  result  of  more  than  a  dozen  direct  contributions  in  the  form  of  draft  sections  and 
the  indirect  contributions  of  the  more  than  one  hundred  subscribers  to  the  SG-C4I  reflector. 
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1.  Introduction 

“The  Simulation  Interoperability  Standards 
Organization  (SISO)  is  dedicated  to  the 
promotion  of  Modeling  and  Simulation  (M&S) 
interoperability  and  reuse  for  the  benefit  of 
diverse  M&S  communities,  including 
developers,  procurers,  and  users,  world-wide” 
[44].  Through  the  Simulation  Interoperability 
Workshops  (SIW),  SISO  provides  a  forum  for 
the  interchange  of  new  ideas  and  concepts 
across  a  broad  M&S  community  and  lays  the 
groundwork  for  subsequent  standards 
development.  As  an  intermediate  step  between 
the  papers  presented  at  the  semi-annual 
workshops  and  standards  development,  SISO 
charters  Study  Groups  (SGs)  to  look  at  specific 
M&S  issues  that  may  ultimately  bear  on  the 
development  of  standards.  A  key  issue  for  both 
the  M&S  and  the  Command,  Control, 
Communications,  Computers,  Intelligence, 
Security,  and  Reconnaissance  (C4ISR) 
communities  is  the  interoperability  between 
C4ISR  systems  and  simulations.  To  address  this 
issue,  SISO  chartered  a  SG  for  M&S— to-C4I 
Interoperability  (SG-C4I).  This  paper  is  the 
final  report  out  of  the  C4I  Study  Group.  It 
discusses  where  we  are ,  where  we  should  go, 
and  recommends  how  to  get  there. 

1.1  Purpose  of  the  SISO  C4I  Study  Group 

The  SISO  M&S-to-C4I  SG  was  chartered  in 
March  1999.  The  Study  Group’s  Terms  of 
Reference  [43]  or  goals,  as  specified  by  SISO's 
Executive  Committee,  are  to: 

□  Recommend  an  approach  or  approaches 
that  will  support  an  appropriate  and 
sufficient  level  of  interoperability 
between  C4ISR  systems  and  High  Level 
Architecture  (HLA)  based  simulations; 

□  Deliver  a  report  which  characterizes 
the  current  “state  of  the  art”  of  M&S- 
to-C4I  interoperability;  and 

□  Develop  a  categorical  bibliography  and 
a  partial  C4I/M&S  interoperability 
lexicon.  (Both  to  be  published 
separately.) 


1.2  Structure  of  this  Report 

To  satisfy  the  Study  Groups  goals,  this  report 
will: 

□  Provide  background  and  current 
information  on  C4ISR  and  Simulation 
Interoperability  efforts; 

□  Provide  a  standards-based  assessment 
of  past  and  current  interoperability 
efforts;  and 

□  Make  recommendations  on  how  the 
Simulation  Interoperability  Workshop 
(SIW)  C4I  Forum  should  proceed  with 
M&S-to-C4I  interoperability  related 
standards  development. 

To  coherently  build  the  case  for  standards 
activity  recommendation!  s)  this  report  is 
organized  to  answer  the  following  questions: 

Where  have  we  been?  In  Sections  2.1,  the 
report  contains  a  synopsis  of  the  history  of  U.S. 
simulation  and  C4ISR  interoperability  in  order 
to  provide  the  reader  with  a  contrast  to  the 
current  state  of  interoperability  between  the  two 
domains. 

Where  are  we  now?  In  the  remainder  of  Section 
2  and  Section  3  the  report  describes  a  number  of 
representative  ongoing  efforts  and  concepts. 

Where  should  we  go?  In  Section  4  we  provide  a 
vision  on  how  to  achieve  M&S-to-C4I 
interoperability  and  a  C4I/M&S  Technical 
Reference  Model  (TRM)  is  described  and 
recommended  for  consideration  by  the  M&S 
community. 

How  do  we  get  there?  In  Section  5  a  set  of 
recommendations  on  how  to  proceed  are 
presented. 

2.  Background  and  Issues 

Motivation  for  improving  the  interoperability 
between  simulations  and  C4ISR  systems 
include: 


□  Simulation  Based  Acquisition  (i.e.. 
Requirements  Development  and 
Analysis,  Testing,  and  Training) 

□  Development  of  Doctrine  and  Tactics 
Techniques,  and  Procedures  (DTTP) 

□  Train  as  you  fight; 

□  Embedded  Training  (both  individual 
and  collective) 

□  Course  of  Action  Development  and 
Analysis 

□  Mission  Planning  and  Rehearsal;  and 

□  Execution  Monitoring. 

The  Department  of  Defense  (DoD)  has 
undertaken  efforts  to  increase  interoperability  - 
via  the  High  Level  Architecture  (HLA)  -  of 
C4ISR  systems  to  simulations.  For  example,  the 
Army  has  an  ongoing  project  to  draft  a  Capstone 
Requirements  Document  for  a  Simulation-to- 
C4I  Interface  (SIMCI)  that  will  define  the  “high 
level  interface  requirements  for  simulations 
(tactical,  training,  analytical,  and  testing)  that 
will  interact  with  C4ISR  systems  of  the  future” 
[14]. 

However,  while  the  M&S  community  is  moving 
on  a  path  towards  standardizing  interfaces  on 
emerging  HLA  approaches,  the  DoD  C4ISR 
community  is  moving  to  standardize  on  the  Joint 
Technical  Architecture  (JTA)  [26]  and  the 
Defense  Information  Infrastructure  Common 
Operating  Environment  (DII  COE)  [9].  As 
noted  in  Flournoy  [17],  Hieb  and  Staver  [21], 
and  Ressler  et  al  [40],  over  the  last  decade, 
uncoordinated  standards  for  M&S-to-C4I 
interoperability  have  been  and  are  currently 
being  developed  by  both  communities.  In 
addition,  Flournoy  [17]  also  discusses  the 
implications  of  these  efforts  on  M&S-to-C4I 
interoperability  and  states  that  standardization, 
occurring  within  both  communities,  raises  hopes 
that  the  number  of  M&S-to-C4I  interoperability 
needs  can  be  reduced  to  a  handful  of  connection 
solutions  at  the  infrastructure  level  between  the 
COE  and  HLA-compliant  Run  Time 
Infrastructures  (RTI). 


□  First,  applicable  standards  (i.e.,  HLA, 

JTA,  DII  COE)  in  both  domains 
continue  to  evolve  rapidly.  Viable 
interfaces  require  absolute 

synchronization  at  intermediate  stages 
of  development  of  both  the  standards 
and  the  effective  implementations. 
Uncoordinated  development  schedules 
challenge  interoperability  solutions 
attempting  to  be  sufficiently  flexible  to 
accommodate  drifting  standards. 

□  Second,  via  the  Levels  of  Information 
Systems  Interoperability  (LISI)  model 
(see  Figure  1 ;  http://www.c3i.osd. 
mil/org/cio/i3/awg  digital  library/inde 

x.htm),  the  Defense  Information 
Systems  Agency  (DISA)  has  embraced 
the  fact  that  interoperability  between 
specific  C4ISR  systems  or  components 
span  multiple  levels. 

□  Third,  each  domain  must  retain  the 
authority  and  responsibility  to  enact 
and  enforce  data  validation, 
certification,  and  security. 

□  Fourth,  each  domain  establishes  and 
enforces  protocols,  procedures, 
conversions,  and  metadata  validation  at 
the  access  points  between  the  separate 
autonomous  systems  supporting  each 
domain.  Data  packet  management  at 
the  access  points  enables  autonomous 
systems  security  and  supports  network 
stability. 

□  Fifth,  active  interfaces  at  the  boundary 
between  the  two  domains  implement 
differential  data  distribution  to  C4ISR 
nodes  and/or  M&S  federates. 

These  factors  must  be  considered  as  we  look  to 
the  current  and  future  challenges  in  C4ISR  and 
simulation  interoperability. 

2.1  Previous  U.S.  Approaches  to  Interfacing 
C4ISR  Systems  and  Simulations 

2.1.1  With  Staff  Level  C4ISR  Systems 


Several  factors  influence  the  viability  of  linking  One  of  earliest  experiments  in  C4ISR  to 

the  M&S  and  C4ISR  domains  [2].  However,  an  simulation  interoperability  -  via  standard 

absolutely  seamless  interface  between  these  two  message  formats  -  was  to  link  the  Tactical 

domains  is  neither  feasible  (as  described  below)  Simulation  (TACSIM)  to  the  U.S.  Automated 

nor  desirable  (as  described  in  Section  2.3).  Defense  Information  Network  (AUTODIN) 

message  system  in  support  of  the  Tactical 
Exploitation  of  National  Capabilities  (TENCAP) 
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Figure  1 .  Levels  of  Information  Systems  Interoperability  (LISI)  Model 


program  in  1980.  TACSIM  generated  Tactical 
Reports  (TACREPs),  Tactical  Electronic 
Intelligence  (TACELINT),  and  a  variety  of  other 
messages  in  U.S.  Message  Text  Format 
(USMTF)  in  both  JANAP  128  and  DOI  103 
formats,  providing  unclassified,  classified 


(collateral),  and  classified  (SCI)  text  message 
traffic  into  the  AUTODIN  system. 

During  an  Ulchi  Focus  Lens  exercise  in  Korea 
in  1990,  this  capability  led  to  a  direct  linkage  - 
via  message  translation  -  from  TACSIM  to  the 
Korea  Combat  Support  System  (KCSS)  and  the 
Korea  Air  Intelligence  System  (KAIS)  for  key 


intelligence  message  traffic.  KCSS  and 
KAIS 

were  the  primary  C4ISR  systems  which 
supported  the  Air  Component  Command  (  ACC) 
of  the  Korean  Combined  Forces  Command 
(CFC).  During  this  same  event,  there  was  a 
linkage  developed  and  implemented  between  the 
Air  Warfare  Simulation  (AWSIM)  and  Tactical 
Receive  Equipment  (TRE)/Tactical  Related 
Applications  (TRAP)  systems.  From  TRAP,  the 
information  was  fed  through  a  TENCAP  project 
component  known  as  the  Air  Defense  Systems 
Integrator  (ADSI).  This  allowed  enemy  aircraft 
tracking  data  to  be  input  to  the  air  defense  cell 
at  the  Control  and  Report  Center  (CRC).  In  this 
way,  there  was  established  a  direct  linkage  of 
simulation  data  to  major  operations  and 
intelligence  centers,  including  the  intelligence 
I&W  centers,  Electronic  Combat  Center, 
Control  and  Report  Center,  and  Combat 
Operations. 

Through  the  mid- 1 990' s,  these  techniques  were 
continued  and  expanded  with  the 
implementation  of  a  Tactical  Information 
Broadcast  Service  (TIBS)  data  link  from  the 
AWSIM,  along  with  a  somewhat  realistic 
representation  of  threat  emitters  and  the 
transmittal  of  that  information  to  Constant 
Source  (CS),  Prototype  Analyst  Workstation 
(PAWS),  Electronic  Processing  and 
Dissemination  System  (EPDS),  Enhanced 
Tactical  User  Terminal  (ETUT),  and  Tactical 
High  Mobility  Terminal  (THMT).  Many  of 
these  were  developed  by  the  Joint  Electronic 
Warfare  Center  (JEWC),  in  support  of  platforms 
such  as  Rivet  Joint,  Senior  Ruby,  and  Guard 
Rail.  Each  of  these  efforts  early  allowed 
additional  simulation  data  to  be  fed  directly  to  a 
variety  of  operational  environments.  But  in 
each  case,  the  interface  was  one-way-only,  from 
the  simulation  to  the  C4ISR  environment. 

In  1994,  the  Warrior  Preparation  Center  built  a 
two  way  interface  between  AWSIM  to  the 
Contingency  Theater  Automated  Planning 
System  (CTAPS).  The  objective  of  the  effort, 
known  as  Project  Real  Warrior  (PRW),  was  to 
maintain  the  existing  simulation  to  C4ISR 
interfaces,  expanded  those  where  possible,  and 
to  establish  a  database  link  from  the  CTAPS  to 
AWSIM.  The  primary  motivation  behind  this 
effort  was  the  reduction  of  manpower  within  the 


exercise  response  cells  by  providing  an 
automated  entry  of  the  Air  Tasking  Order 
(ATO)  into  AWSIM.  Since  the  ATO  can 
contain  upwards  of  2000  missions  per  day,  this 
offered  a  significant  reduction  in  manpower 
requirements. 

In  parallel  with  this  effort,  the  United  States  Air 
Force  (USAF)  Battlestaff  Training  School 
(BTS),  known  as  “Blue  Flag,”  had  another 
program,  a  CTAPS  to  Wargame  Interface 
Controller  (CWIC)  working,  which  had  similar 
objectives  to  PRW,  but  with  the  added  objective 
of  providing  automated  synchronization  of 
databases  between  CTAPS  and  AWSIM.  This 
allowed  unit  order  of  battle  information  to  flow 
directly  from  CTAPS  to  AWSIM,  simplifying 
the  process,  reducing  time  required  for  database 
builds,  and  ensuring  consistency  between  the 
two  databases. 

While  these  projects  were  occurring,  in  January 
1994  preparations  were  on  going  for  an  exercise 
in  Japan,  called  Keen  Edge.  This  was  being 
supported  by  the  Joint  Warfighting  Center 
(JWFC),  using  the  Joint  Theater  Level 
Simulation  (JTLS).  During  an  extremely 
shortened  development  cycle  (less  than  two 
months),  a  two  way  interface  -  using  message 
parsing  augmented  by  database  mapping  -  was 
established  between  JTLS  and  CTAPS.  This 
allowed  an  ATO,  received  from  CTAPS,  to  be 
translated  into  flight  orders  and  routes  for  JTLS, 
and  entered  into  the  simulation.  In  turn, 
simulation  generated  Tactical  Data  Link 
(TADIL)  formatted  messages  could  be  provided 
to  operational  personnel.  In  addition,  enemy 
Electronic  Intelligence  (ELINT)  data  was 
formatted  and  broadcast  via  operational  links  to 
the  entire  TRAP  network. 

At  about  the  same  time,  in  support  of  the  U.S. 
Army  Text  and  Experimentation  Command 
(TEXCOM),  the  Army  Experimentation  Station 
(AES)  was  developing  a  suite  of  interfaces, 
called  the  Simulation  Support  Modules  (SSM), 
between  a  variety  of  C4ISR  systems,  the  Corps 
Battle  Simulation  (CBS),  and  the  Combat 
Service  Support  Training  Simulation  System 
(CSSTSS).  The  C4ISR  systems  stimulated 
included,  the  All  Source  Analysis  System 
(AS AS),  the  Maneuver  Control  System  (MCS), 
the  Advanced  Field  Artillery  Tactical  Data 
System  (AFATDS),  the  Forward  Area  Air 


Defense  Command.  Control,  and  Intelligence 
(FAADC2I)  system,  and  the  Combat  Service 
Support  Control  System  (CSSCS).  This  suite  of 
interfaces  -  via  message  parsing  augmented  by 
database  mapping  -  provided  a  two-way  feed 
with  AFATDS  (e.g..  Calls  for  Fire)  and  a  one 
way  feed  with  the  other  four  systems.  The 
information  provided  from  the  simulation 
included  status  information,  as  well  as  a  variety 
of  Command  and  Control  (C2)  actions. 

These  three  early  efforts  in  many  ways 
influenced  the  development  of  the  Modular 
Reconfigurable  C4ISR  Interface  (MRCI)  [19  & 
31],  which  attempted  to  develop  a  standardized 
data  output  stream  from  a  simulation  to  C4ISR 
systems  and  to  incorporate  a  standardized 
method  for  converting  C4ISR  system  inputs  to 
the  simulations.  This  effort  was  initially 
supported  by  DMSO  and  later  by  the  Defense 
Advanced  Research  Project  Agency  (DARPA). 
MRCI  was  demonstrated  during  the  Synthetic 
Theater  of  War  (STOW)  98  experiment.  While 
many  aspects  of  the  MRCI  experiment  were 
similar  to  earlier  efforts  in  C4ISR  to  simulation 
interoperability,  there  were  two  unique  features. 

One  unique  MRCI  feature  was  the  attempt  to 
develop  a  standard  interface  to  the  C4ISR 
environment,  in  contrast  to  previous  efforts, 
which  in  general  created  unique  interfaces  to 
each  C4ISR  system.  The  other  unique  aspect 
was  the  attempt  to  develop  and  mature  a 
technology  for  translating  command  and  control 
directives  (or  commands)  into  simulation 
“orders.”  For  this  a  tool  known  as  the 
Command  and  Control  to  Simulation  Interface 
Language  (CCSIL)  was  developed. 

Concurrently,  with  MRCI  the  Air  Force  and 
Army  moved  forward  with  a  direct  data 
download  interface  between  AWSIM  and 
CTAPS.  Additionally,  this  two  way  interface 
sent  orders  and  commands  to  AWSIM  while 
passing  the  status  of  the  combat  entities  back  to 
CTAPS  in  the  correct  format,  with  doctrinally 
correct  content  and  timing. 

In  1997  the  Army  began  an  effort  to  replace  the 
SSMs.  Called  the  Run  Time  Manager  (RTM),  it 
extended  the  SSM's  message  parsing  and 
database  augmentation  by  capturing  information 


via  Distributed  Interactive  Simulation  (DIS) 
Protocol  Data  Units  (PDUs)  and  translating 
embedded  CCSIL-like  data. 

2.1.2  With  Entity  Level  C4ISR  Systems 

While  most  of  the  discussion,  to  this  point,  on 
the  history  of  C4ISR  to  simulation 
interoperability  has  dealt  with  staff  level  C4ISR 
systems,  there  have  been  a  number  of  efforts  to 
develop  these  interfaces  at  the  entity,  and  even 
the  engineering  level. 

One  of  the  early  efforts  in  this  arena  was  the 
development  of  a  Live-to-Virtual  Interface 
Device  (LIVID)  for  use  in  the  Army's  1995 
Focused  Dispatch  Advanced  Warfighter 
Experiment  (AWE).  Focused  Dispatch's  LIVID 
provided  a  voice  and  data  interface  between  a 
Single  Channel  Ground  and  Airborne  Radio 
System  (SINCGARS)  radio  and  a 
CECOM/MITRE  SINCGARS  Radio  Model 
(SRM).  The  LIVIDs,  SRMs,  and  SINCGARS 
radio  base  stations  were  used  together  to  link  the 
virtual  and  live  domains.  Both  the  real 
SINCGARS  in  the  live  environment  and  the 
SRMs  in  the  virtual  environment  were 
connected  to  real  C2  devises  hosted  on  laptop 
computers.  The  SRM-LIVID  linkage  between 
the  C2  devices  and  the  simulation  environment 
included  a  C2-system-specific  interface,  a  core 
communications  model,  and  a  simulation- 
network  interface. 

This  effort  ran  in  parallel  to,  and  was  succeeded 
by,  the  Tactical  Internet  Model  (TIM)  suite  of 
simulation  software.  The  TIM  suite  roots  are  in 
the  SRM,  initially  developed  in  support  of 
Focused  Dispatch  AWE.  Later  versions  of  TIM 
were  implemented  to  support  not  only  training, 
but  also  analysis  and  testing.  The  TIM  suite 
provided  a  realistic  communications 
environment  for  training  using  Applique’  (the 
predecessor  to  the  Force  XXI  Battle  Command 
Brigade  and  Below  (FBCB2)  system),  prior  to 
the  Task  Force  XXI  AWE.  Follow-on  efforts 
have  incorporated  FBCB2,  as  well  as  Global 
Positioning  System  (GPS)  devices  and 
ULA/Distributed  Interactive  Simulation  (DIS) 
protocol-compliant  simulations. 


During  this  same  timeframe,  at  the  USAF  BTS, 
an  interface  was  developed  from  AWSIM- 
Scenario  Toolkit  and  Generation  Environment 
(STAGE).  This  interface  provided 
direct 

stimulation  to  air  defense  radars.  AWSIM- 
STAGE  was  used  during  Roving  Sands  1997  (a 
large  joint  training  exercise  which  brought 
together  constructive,  virtual,  and  live 
simulations). 

In  the  fall  of  1994,  the  Chief  of  Staff  of  the 
Army  (CSA)  tasked  the  commander  of  Space 
and  Missile  Defense  Command  (SMDC)  to 
build  a  Tactical  Operations  Center  (TOC)  that 
would  integrate  the  four  pillars  of  Theater 
Missile  Defense  (TMD)  by  providing  a  single 
focus  to  manage  the  “sensor  to  shooter” 
activities  required  to  address  time  critical 
targets.  The  primary  tool  developed  by  this 
effort  was  the  Tactical  Simulation  Interface  Unit 
(TSIU).  The  TSIU  reads  simulation  (sensor 
based)  signal/transmitter  PDUs  from  a  DIS 
based  simulation  network  and  translates  this 
information  into  the  appropriate  command  and 
control  workstation.  The  TSIU  does  not  directly 
read  entity  or  aggregate  PDU  information,  nor 
does  it  provide  truth  data  to  the  command  and 
control  workstations.  A  sensor  must  identify 
and  report  (for  enemy  forces)  or  a  command  and 
control  entity  must  report  (for  friendly  forces) 
via  the  signal/transmit  PDU  in  order  for  tactical 
messages  to  be  forwarded  to  the  C2  workstation. 

The  TSIU  was  initially  demonstrated  in  the 
1994  Atlantic  Resolve  exercise.  Since  that  time 
it  has  participated  in  exercises  ranging  from 
battalion  through  CINC  level.  TSIU  has  been 
used  to  stimulate  all  five  of  the  Army’s  ATCCS 
systems,  as  well  as  FBCB2. 

In  April  2000,  Janus  (an  Army  constructive 
simulation)  was  interfaced  -  via  the  Simulation 
Testing  Operations  Rehearsal  Model  (STORM) 
-  with  both  the  Army’s  five  ATCCS  systems 
and  FBCB2  to  support  the  second  FBCB2 
Limited  User  Test  (LUT).  STORM  was 
developed  by  the  Army  Operational  Test  and 
Evaluation  Command  (ATEC);  during  the  LUT, 
it  stimulated  two  live  Brigade  Combat  Team 
(BCT)  TOCs,  two  live  Task  Force  TOCs,  two 
live  task  forces,  and  a  live  opposing  force 
(OPFOR)  armor  battalion.  STORM  was  used  to 
simulate  two  additional  Task  Forces  and 


associated  BCT  slice  elements,  to  ensure 
realistic  Tactical  Internet  (TI)  communications 
loading.  It  also  wrapped  simulated  OPFOR 
units  around  the  live  OPFOR  battalion  in  order 
to  provide  a  realistic  threat  environment.  As 
described  in  McConnell  et  al  [33],  STORM 
generated  Situation  Awareness  (SA),  C2,  and 
intelligence  Joint  Variable  Message  Format 
(JVMF)  messages  -  via  the  JVMF  Library 
(version  15.6)  -  for  the  simulated  forces  and 
transmitted  them  to  the  live  forces  over  the  TI. 
The  simulated  forces  appeared  on  the  live  force 
FBCB2  screens,  and  the  live  force  appeared  on 
the  STORM  screens.  FBCB2-equipped  live 
forces  were  not  able  to  differentiate  the  live 
forces  from  the  STORM  simulated  forces. 

2.2  Previous  and  Ongoing  International 
Efforts  to  Couple  M&S  and  C4ISR  Systems 

This  subsection  gives  a  rough  overview  on 
what's  going  on  in  the  international  community 
in  the  area  of  coupling  (or  interfacing)  C4ISR 
systems  and  simulations.  The  North  Atlantic 
Treaty  Organization  (NATO)  M&S  Master  Plan 
[35]  defines  at  least  two  application  domains  for 
which  C4ISR  systems  and  simulation  systems 
have  to  be  coupled: 

□  For  Computer  Assisted  Exercises 
(CAX)  it  is  essential  that  the  warfighter 
can  be  trained  as  he  is  supposed  to  fight 
(i.e.,  that  his  “go  to  war”  Combat 
Information  System  (CIS)  should 
reflect  present  information  about 
simulated  reality  in  the  same  way  it 
would  in  a  real  operation).  Thus,  the 
simulation  system  generating  the 
information  and  executing  the  orders 
the  training  audience  gives  to  their 
simulated  units  has  to  be  coupled  with 
the  CIS. 

□  For  Operation  Research  Support  to 
Operations  (i.e.,  online  alternative 
course  of  action  analysis,  optimization 
problems,  what-if  analyses,  etc.),  the 
integration  of  respective  applications 
into  the  C4ISR  systems  is  necessary. 
Simulation  systems  are  a  potential 
candidate  for  this  functionality  [53  & 
54], 


2.2.1  NATO  Efforts 


Supreme  Headquarters  Allied  Powers  Europe 
(SHAPE)  is  planning  to  develop  a  CAX  Center 
for  training  on  joint  operations  at  its  level  of 
command.  Within  the  CAX  Center,  the  CIS  of 
SHAPE  will  be  integrated,  in  part  to  insure 
realistic  training  of  commanders  and  their 
forces. 

Supreme  Allied  Commander  Atlantic 
(SACLANT)  realizes  the  coupling  of  its 
Maritime  Command  and  Control  Information 
System  (MCCIS)  with  maritime  simulation 
systems  using  the  Gold  message  format  to  share 
necessary  information.  Again,  the  application 
domain  is  CAX. 

NC3A  is  working  mainly  with  JTLS  and  is  also 
focusing  on  CAX.  Under  Project  XC  (CAX)  at 
NC3A,  the  team  has  coupled  several  CIS  and 
simulations  for  exercise  purposes  using  different 
technical  approaches. 

2.2.2  National  Level  Efforts 

France  uses  its  Stradivarius  simulation  system 
for  CAX  applications  as  well  as  for  after  action 
analysis  and  simulation  based  acquisition.  One 
of  the  purposes  for  developing  this  simulation 
system  was  to  test  the  functionality  and 
efficiency  of  the  air  defense  system,  including 
radar’s,  weapon  systems,  and  command  and 
control.  Thus,  the  interface  to  these  air  defense 
systems  has  been  an  integral  part  of  Stradivarius 
from  its  inception.  Stradivarius  supports 
AdatP3  messages  and  Datalink  (Surveillance 
and  Control):  Link  1,  Link  11,  Link  14,  Link  16 
and  specific  radar  links. 

Germany  promotes  the  federation  approach  for 
the  coupling  of  C4ISR  systems.  It  is  one  of  the 
leading  nations  concerning  data  management 
having  already  established  a  respective  federal 
agency  for  data  management  (Daten- 
managementorganisation  der  Bundeswehr, 
DMO  Bw). 

□  The  same  integration  method  used  for 
C4ISR  systems  is  also  being  used  for 
decision  support  simulation  systems. 

□  For  CAX  purposes,  alternative  means 
of  stimulating  C4ISR  systems  are  being 
evaluated.  The  use  of  standard 
message  interfaces  is  one  candidate  and 


the  use  of  special  domain  areas  within 
the  databases  (i.e.,  the  definition  of  a 
“simulation  system  user”  within  the 
C4ISR  system)  is  also  being  proposed. 

□  For  the  simulation  systems,  the  German 
Proposed  Standard  Interface  for 
Simulation,  introduced  by  [34],  is 
planned  to  become  the  standard 
interface  for  linking  M&S-to-C4ISR. 

Italy  is  working  on  a  federation  solution  using 
ATCCIS  as  a  common  shared  data  model.  In 
some  areas,  they  are  working  closely  together 
with  Spain.  However,  their  work  focuses 
exclusively  on  the  integration  of  C4ISR  systems. 
The  use  of  simulations  -  to  stimulate  Italian 
C4ISR  systems  -  is  only  at  the  edge  of  the  scope. 

Netherlands  coupled  its  KIBOWI  system  (Kiviet 
and  Borawltz;  the  two  developers)  with  several 
national  CIS.  KIBOWI  is  similar  to  CAX 
system  with  a  decision  support  system  for  online 
analyses.  The  coupling  is  done  by  data 
replication  of  respective  data  domains  between 
the  two  systems. 

Portugal  has  no  problem  in  coupling  its  CAX 
system  Visualizafao  Grafica  do  Terreno  em 
Modelo  Digital  3D  (VIGRESTE)  with  Allied 
Tactical  Command  and  Control  Information 
System  (ATCCIS)  compliant  C4ISR  system. 
The  VIGIRESTE  model  developers  chose 
ATCCIS  as  the  basis  for  the  object  model  being 
used  within  their  simulation  model.  Thus,  a  real 
fusion  approach  is  working  that  have  been 
planned  from  the  beginning.  This  was  possible 
since  Portugal  started  from  scratch  in  both  the 
C4ISR  and  CAX  worlds  with  a  harmonized 
approach. 

Sweden  participates  in  the  Partnership-for-Peace 
(PfP)  training  efforts  as  a  leading  nation,  using 
TYR,  a  simulator  to  operate  a  game  at  command 
level.  Sweden  has  begun  development  of  next 
generation  where  HLA  will  be  the  architecture 
of  the  system.  Sweden  has  also  started 
investigating  how  HLA  can  be  a  part  of  the 
Swedish  Armed  Forces  C4ISR  architecture  and 
how  to  apply  a  model  based  way  of  thinking  in 
C4ISR-systems.  ATCCIS  is  being  considered  in 
connection  with  this  work.  Sweden  is  one  of 
thirteen  members  in  the  Western  Europe 
Armament  Group  (WE AG)  EUCLID  program 
Common  European  Priority  Areas  (CEPA) 


11:13  titled  “Realising  the  Potential  of 
Networked  Simulation  in  Europe.” 

The  United  Kingdom  gained  experience  early  on 
during  the  FlasHLAmp  experiments.  Where 
C4ISR  systems  were  coupled  with  various 
combat  simulations. 

Many  efforts  are  ongoing  within  the 
International  community.  However,  these 
efforts  are  largely  uncoordinated.  As  a  starting 
point,  lessons  learned  should  be  shared  among 
nations  through  the  SIW  C4I  and  International 
Forum. 

2.3  The  NATO  and  DoD  Modeling  and 
Simulation  Master  Plans 

In  late  1994  and  early  1995,  the  Defense 
Modeling  and  Simulation  Office  (DMSO) 
conducted  a  baseline  assessment  of  all  DoD 
M&S.  From  this  assessment,  DMSO  identified 
six  DoD-wide  M&S  objectives  that  were,  in 
October  1995,  published  in  DoD's  first  M&S 
Master  Plan;  DoD  5000. 59-P,  Modeling  and 
Simulation  Master  Plan  (MSMP)  [10]. 

For  each  objective,  DoD  5000. 59-P  identifies 
key  issues  and  actions  [10].  Because  no  single 
model  or  simulation  can  meet  all  of  the  needs  of 
the  M&S  community,  the  objectives  do  not 
identify  any  specific  solution.  Rather,  each 
objective  identifies  those  aspects  that: 

□  Are  common  across  all  M&S  (both 
military  and  non-military); 

□  Foster  credibility  and  re-use  [or  cost 
avoidance];  and. 

□  Where  appropriate,  ensure 

interoperability. 

DoD  5000. 59-P  establishes  the  HFA  and 
Conceptual  Modeling  of  the  Mission  Space 
(CMMS)  as,  respectively,  the  first  and  second 
components  of  the  DoD  M&S  Technical 
Framework  [10  &  12]. 

Taking  the  DoD  MSMP  as  one  input,  in 
November  1996,  NATO  began  to  develop  a 
NATO  MSMP.  The  Conference  of  National 
Armaments  Directors  (CNAD)  established  a 
Steering  Group  on  NATO  Simulation  Policy  and 
Applications  with  a  mandate  to  craft  an  Alliance 
approach  to  simulation  in  order  to  improve 


Alliance  operations.  The  resulting  efforts 
resulted  in  the  NATO  Document  AC/323 
(SGMS)  D/2  [35].  It  establishes  a  co-operative 
approach  for  applying  advanced  simulation 
techniques  to  aid  in  satisfying  the  needs  of  the 
NATO  Alliance  and  its  member  nations.  It  is 
assumed  that  successful  execution  of  the  master 
plan  will  promote  the  aim  of  Alliance-wide 
simulation  interoperability  and  reuse,  while  also 
providing  national  and  NATO  bodies  with 
significant  modeling  and  simulation  interest, 
with  the  necessary  latitude  to  meet  their  specific 
needs. 

The  NATO  MSMP  identifies  four  areas  where 
M&S  can  provide  a  “value  added:” 

□  Defense  Planning, 

□  Training, 

□  Exercises,  and 

□  Support  Operations. 

The  objective  to  couple  C4ISR  systems  and 
respective  simulation  systems  is  an  explicit  topic 
for  the  training,  exercises,  and  support 
operations  domains. 

2.3.1  HLA 

Objective  1  of  the  DoD  M&S  Master  Plan  states, 
“Provide  a  common  technical  framework  for 
M&S.”  Sub-objective  1-1  includes  the 
establishment  of  a  common,  high  level 
simulation  architecture  to  facilitate 
interoperability  of  all  types  of  simulations 
among  themselves  and  with  C4ISR  systems,  as 
well  as  facilitate  the  reuse  of  M&S  components. 
To  meet  this  objective  the  Under  Secretary  of 
Defense  for  Acquisition  and  Technology  (USD 
A&T)  designated  the  HFA  as  the  standard 
technical  architecture  for  all  DoD  simulations 
[26]. 

Future  DoD  C4ISR  interface  developers  must 
develop  interfaces  that  take  into  account  not 
only  the  HFA,  but  also  the  DII  COE  and  JTA 
mandated  message  formats,  data  models,  and 
data  exchange  standards. 

2.3.2  Conceptual  Models  of  the  Mission 
Space  (CMMS) 

CMMS  provides  simulation-independent, 
warfighter-based  descriptions  of  the  real  world. 


CMMS  does  this  by  linking  Subject  Matter 
Experts  (SMEs)  with  simulation  developers  and 
users  via: 

□  Actual  subject  matter  descriptions  in 
the  form  of  knowledge  acquisition 
products; 

□  A  common  repository  for  use  and  re¬ 
use;  and 

□  A  technical  framework  for  integration 
and  interoperability  of  the  knowledge 
acquisition  products  registered  in  the 
common  repository  [13]. 

Known  as  Mission  Space  Models  (MSMs),  these 
subject  matter  descriptions  are  the  primary 
components  of  DMSO’s  CMMS  program  [23]. 
Intended  to  describe  how  a  specific  task  or 
action  is  conducted,  MSMs  -  via  a  hierarchical 
form  where  each  subordinate  level,  sub-process, 
or  function  provides  greater  detail  -  are  the  first 
abstraction  of  real  world  processes  [13  &  23]. 

With  regard  to  M&S-to-C4I  interoperability, 
MSMs  -  if  used  -  have  the  potential  to  make 
personnel  attempting  to  link  M&S  and  C4ISR 
systems  realize  that  passing  messages,  whether 
in  the  form  of  interactions  or  objects,  between 
simulations  and  C4ISR  systems  is  comparatively 
straight  forward.  Far  more  difficult 
interoperability  problems  are  in  the  areas  of 


database  synchronization,  data  cohesion,  and 
data  collection  (e.g..  After  Action  Reviews). 

2.4  JTA 

The  DoD  JTA  [26]  has  three  mutually 
supporting  objectives.  The  first  is  to  provide  the 
foundation  for  interoperability  and  seamless 
flow  among  all  tactical,  strategic,  and  sustaining 
base  systems  that  produce,  use  or  exchange 
information  electronically.  The  second  objective 
is  to  provide  guidelines  and  standards  for  system 
development  and  acquisition  that  will 
dramatically  reduce  cost,  development  time,  and 
fielding  time  for  improved  systems.  The  third 
objective  is  to  influence  the  direction  of  the 
information  industry’s  technology  development 
and  research  and  development  investment  so 
that  it  can  be  more  readily  leveraged  in  DoD 
systems. 

To  better  understand  the  role  of  M&S  in 
supporting  these  objectives,  we  note  that  M&S  is 
used,  as  shown  in  Figure  2,  to  support  the 
analysis  and  development  of  the  real  world 
Operational  Architecture  (OA)  and  System 
Architecture  (SA)  views.  For  example,  for  the 
OA  view,  information  models  are  built  (often 
using  IDEF0/IDEF1X)  to  represent  real-world 
systems  and  the  interfaces  and  the  data  flow 
between  them.  These  models  are  of  three  basic 
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Figure  2.  M&S  Role  in  Support  of  the  Operational,  Systems,  and  Technical  Architecture  Views 


types:  activity,  data,  and  interface  models. 
Activity  models  are  representations  of  the 
mission  area  applications  or  activities  that  an 
organization  must  perform  to  achieve  its 
mission.  They  document  processes  and  data 
flows,  can  be  validated  against  the  requirements 
and  doctrine,  and  approved  by  the  operational 
sponsor.  As  such,  they  help  define  both  what  to 
build  and  the  information  flows  necessary  to 
support  command  and  control  of  these  units, 
based  on  requirements.  The  data  models  are 
used  as  a  logical  basis  for  physical  data 
exchange  and  shared  data  structures  including 
message  formats  and  schema  for  shared 
databases.  Interface  models  represent 
connection  solutions  at  the  infrastructure  level 
between  the  COE  and  HLA-compliant  RTIs. 
For  the  SA  view,  M&S  is  used  to  develop  the 
“wiring”  diagram  that  shows  how  the  various 
elements  communicate  with  one  another,  thus 
providing  the  communications  design  for  the 
units  and  processes  that  the  OA  view  specifies. 
However,  it  is  unclear  how  the  JTA  applies  to 
such  uses  of  M&S. 

The  JTA  provides  a  set  of  standards,  some  of 
which  are  particularly  relevant  to  M&S  in  the 
areas  of  data  models  and  software  architectures. 
For  the  C4ISR  domain,  these  are  specified  in  the 
JTA  as  the  C4ISR  common  data  models  and  the 
DII  COE  architecture.  The  DII  COE  consists  of 
common  reusable  software  components.  Within 
the  JTA,  M&S  is  a  separate  domain  with  its  own 
annex.  In  that  annex  the  HLA  is  specified  as 
the  set  of  relevant  standards  and  the  software 
architecture  for  M&S.  However,  the  M&S 
annex  is  not  clear  on  the  relationship  between 
the  C4ISR  domain  and  the  M&S  domain.  This 
has  led  to  confusion  on  which  set  of  standards 
apply  to  simulations,  C4ISR  systems,  and  C4ISR 
Interfaces. 

2.5  DII  COE 

In  JTA  version  2.0  [26]  DoD  adopted  the 
Defense  Information  Infrastructure  Common 
Operating  Environment  (DII  COE)  concept  and 
mandated  the  DII  COE  baseline  specification 
and  the  DII  COE  integration  and  runtime 
specification.  The  DII  COE  is  mission 
application  independent,  as  well  as: 

□  An  architecture; 

□  An  approach; 


□  A  collection  of  reusable  software; 

□  A  software  infrastructure;  and 

□  A  set  of  guidelines  and  standards. 

Per  the  DII  COE  Architecture  Oversight  Charter 
[9],  portions  of  the  DII  COE  are  being  updated 
using  requirements  generated  by  20  joint  service 
Technical  Working  Groups  (TWGs).  The  Army 
is  the  lead  for  several  TWGs  that  are  critical  to 
M&S  C4ISR  interface  developers,  such  as:  the 
COE  Message  Processor  (CMP), 
Communications  Services,  Data  Access 
Services,  and  Alerts.  There  are  also  TWGs  for 
the  Common  Operational  Picture;  Visualization 
and  3D;  and  Mapping,  Charting,  Geodesy,  and 
Imagery  via  the  Joint  Mapping  Toolkit  (JMTK). 
Just  recently,  the  DII  COE  Executive  Oversight 
Group  established  a  new  TWG  -  M&S  -  chaired 
by  DMSO. 

2.6  Information  Assurance/Security 

Information  Assurance  (IA)  encompass  all 
actions  that  “protect  and  defend  information  and 
information  systems  by  ensuring  their 
availability,  integrity,  authentication, 
confidentiality,  and  non-repudiation.  This 
includes  providing  for  restoration  of  information 
systems  by  incorporating  protection,  detection, 
and  reaction  capabilities”  [25].  Security 
demands  an  ability  to  tailor  access  to  system 
components  in  concert  with  policy  to  enable 
forces  to  meet  mission  and/or  training 
requirements.  Past  efforts  to  link  M&S  and 
C4ISR  domains  have  largely  ignored  IA/security 
issues.  The  general  focus  has  been  on  enabling 
connections;  not  on  establishing  access  security 
or  providing  tools  to  ensure  information 
integrity  [2], 

As  more  systems  are  linked,  as  applications  are 
extended,  and  as  more  users  are  added,  the 
importance  of  information  assurance  grows.  In 
the  future,  IA  must  be  a  major  consideration  in 
designing  links  between  and  within  M&S  and 
C4ISR  domains.  Training  objectives  and 
political  goals  will  increase  the  need  to  link 
federations  with  multi-national  forces  while 
each  force  uses  its  native  simulations  and  C4ISR 
systems.  This  drive  to  extend  the  training 
audience  will  not  offset  the  need  to  “train  as  you 
fight.”  Hence,  multi-domain  frameworks  will 
demand  improved  IA  designs  with  security 


features  that  permit  authorized  access  while 
enhancing  protection. 

Implementation  of  data  filters  within  a  domain 
has  significant  performance  implications  [16]. 
Hence,  designs  should  include  special  security 
features  at  the  intersecting  boundary  layers 
between  domains.  Thus,  users  and  applications 
within  one  domain  may  be  correctly  restrained 
from  access  or  interference  within  another. 
Hence,  totally  seamless  links  between  domains 
is  not  desirable.  Rather,  interfaces  must  strive 
to  provide  facile,  automated,  consistent  access 
across  these  domain  boundaries  to  authorized 
users  and  authorized  programs. 

Within  the  C4ISR  domain,  systems  are  based  on 
a  variety  of  protocols.  These  differences  impose 
barriers  to  interoperability  within  this  single 
domain.  Addition  of  M&S  components  to  this 
equation  will  not  resolve  this  C4ISR 
interoperability  issue.  However,  the  DoD 
community  has  taken  strides  to  provide  both 
near  and  long  term  solutions.  The  Office  of  the 
Secretary  of  Defense  (OSD)  and  DISA  have 
worked  to  develop  an  interoperability  model, 
LISI,  discussed  in  detail  in  Section  4.3. 
Moreover,  near  term  projects  have  implemented 
viable  interfaces  between  disparate  systems  as 
demonstrated  by  the  Rosetta  program  in  the 
Lin  k- 1 6/ Variable  Message  Format  (VMF) 
Conversion  Advanced  Concept  Technology 
Demonstration  [57].  However,  this  gateway 


fails  to  include  critical  security  features  or 
record  and  monitor  critical  metadata.  Thus  in 
the  near  term,  reusable  links  between  the  HLA 
RTI  and  target  elements  of  the  C4ISR  domain 
could  leverage  common  gateways  when  these 
extended  with  security  features  and  metadata 
support.  In  the  long  term,  other  options  may  be 
developed. 

2.7  Relationship  between  C4ISR  and 
Simulation  Domains 

Figure  3  shows  a  generalization  of  how  most 
DIS  M&S-to-C4I  interfaces  are  currently 
implemented.  Because  the  DIS  standard  does 
not  align  well  with  current  tactical  message 
formats,  there  must  be  a  software  translator  to 
perform  the  interface  functions.  Only  a  limited 
amount  of  information  passes  over  the  interface, 
and  there  are  many  design  options,  so  that  each 
interface  project  will  usually  develop  new 
software.  Projects  have  also  interfaced  C4ISR 
equipment  to  the  HLA,  such  as  the  Modular 
Reconfigurable  C4I  Interface  [19  &  31].  Such 
projects  have  emphasized  the  need  to  minimize 
translation  and  it’s  overhead  through  use  of 
common  data  elements  [31  &  49]. 

At  least  one  missing  piece  is  a  data  interchange 
format  that  assists  in  the  data  alignment  of 
C4ISR  systems  with  simulations.  A  good 
example  of  this  is  SEDRIS  (http://www.sedris. 
qrg).  The  Synthetic  Environment  Data 


Figure  4.  A  C4I  Developer’s  View  of  C4I  to  M&S  Interface  Standards 


Representation  and  Interchange  Specification 
(SEDRIS)  could  be  a  Data  Interchange  Format 
(DIF)  between  the  simulation  terrain  formats 
(such  as  SI 000  or  Standard  Interchange  Format 
(SIF))  and  the  C4ISR  terrain  formats  (Digital 
Terrain  Elevation  Data  (DTED)  or  Vector 
Product  Format  ( VPF)).  Neither  the  simulations 
nor  the  C4ISR  systems  use  the  SEDRIS  format, 
but  it  allows  conversion  of  data  by  providing  a 
unifying  representation. 

There  is  a  large  difference  in  viewpoint  between 
the  developers  of  Simulations  and  the  developers 
of  C4ISR  systems,  regarding 

applicable 

standards.  C4ISR  developers  feel  strongly  that 
simulations  should  use  the  data  elements  that 
real  systems  use.  This  could  lead  to  a  standards 
framework,  as  shown  in  Figure  4,  with  a  DII 
COE  segment  in  the  simulation  for  direct 
database-to-database  data  element  transfer. 


Figure  5  shows  a  standards  based 
interoperability  solution  that  is  simulation 
oriented.  It  assumes  that  the  HLA  will  be 
hosted  on  C4ISR  platforms,  possibly  as  a  DII 
COE  segment.  But,  the  SG’s  research  indicates 
that  C4ISR  developers  are  not  familiar  with  the 
HLA  and  have  traditionally  not  accepted  this  as 
a  valid  requirement  for  their  system. 

Figures  4  and  5  also  show  that  making  a  DIF  - 
or  an  Application  Programmer’s  Interface  (API) 
-  a  standard  does  not  constrain  the  architecture. 
There  will  still  be  a  need  for  a  DIF  even  if  one 
architecture  predominates.  Until  both 
architectures  have  been  designed  with,  and  use 
the  same  underlying  data  elements  there  will  be 
a  need  for  translation.  However,  a  good 
standard  will  minimize  translations. 


A  framework  must  still  be  developed  for 
aligning  JTA  M&S  and  C4ISR  standards. 

2.8  DoD  Policy  Concerning  C4ISR  and 
Simulation  Interoperability 

The  labyrinth  of  interoperability  policy  can 
present  many  obstacles  to  unwary,  unsuspecting 
C4ISR  or  M&S  program  managers,  system 
developers,  and  users.  Sutton  [48]  conducted  an 
analysis  of  military  interoperability  policy  to 
provide  a  roadmap  of  this  complex,  confusing, 
and  often  frustrating  maze  of  policies. 

2.8.1  C4ISR  Interoperability  Policy 
Elements 

The  following  types  of  interoperability  policy 
elements  were  found  in  C4ISR  interopera¬ 
bility 

policy  documents,  but  not  in  M&S  policy  docu¬ 
ments: 

□  Certification  and  Re-certification 

□  Compatibility 

□  Doctrine 

□  Integration 

□  Interface  Standards 

□  Interoperability  Problem  Reporting 

□  Interoperability  Requirements 

□  Interoperability  Testing,  Operational 
Testing  and  Evaluation,  Testing  and 
Evaluation 


□  Mapping,  Charting,  Geodesy  Data 
Standards  and  Specifications 

□  Mission  Need  Statement  (MNS)  and 
Operational  Requirements  Document 
(ORD) 

□  Interoperability  Waivers 

2.8.2  M&S  Interoperability  Policy 
Elements 

The  following  types  of  interoperability  policy 
elements  were  found  in  M&S  interoperability 
policy  documents,  but  not  in  C4ISR  policy 


documents 

□ 

Accreditation 

□ 

Common  Databases  and  Tools 

□ 

Data  Interchange  Standards 
Protocols  Establishment 

and 

□ 

Data  Verification,  Validation, 
Certification 

and 

□ 

Federations 

□ 

HLA 

□ 

Internet  Standard  and  Protocol 

Establishment 

□ 

No-Pay/No-Play  Deadlines  for 
Conformance 

HLA 

□ 

Object  Model  Data  Dictionary  (OMDD) 

□ 

Object  Model  Template 

Interchange  Format  (OMTDIF) 

Data 

□ 

Risk  Management  (Secretary  of  the 
Navy  Instruction  (SECNAVINST) 

5200.38  only) 

□ 

Standard  Simulator  Data 

Base 

Federation  Object  Model 


Figure  5.  A  Simulation  Developer’s  View  of  C4I  to  M&S  Interface  Standards 


Interchange  Format  (SIF) 

□  Synthetic  Environment  Data 

Representation  Interchange 

Specification  (SEDRIS) 

2.8.3  Interoperability  Elements  in  both 
C4ISR  and  M&S  Policy  Documents 

The  following  types  of  interoperability  policy 
elements  were  found  in  both  C4ISR  and  M&S 
interoperability  policy  documents: 

□  Data  Interchange  Standards  for 
Applications  Sharing 

□  DII  COE 

□  Human-Computer  Interface  Standards 

□  Information  Modeling,  Processing, 
Systems  Security,  and  Transfer 
Standards 

□  Internet  5 -Layer  Network  Model 

□  Internet  Standards  and  Protocols 

□  Interoperable  with  Joint  and  Combined 
C4ISR  Systems  and  Operations 

□  JTA 

□  Open  Systems  Architecture  Standards 
and  Protocols 

□  Seamless,  Transparent  Open  Systems 
Infrastructure 

□  Standard  Data  Elements  Exchanged  by 
C4ISR  Systems  and  M&S  Applications 

□  System  Design  and  Integration  Rules 
for  Technical  Architecture 

2.8.4  Interoperability  Elements  not  in  Either 
C4ISR  or  M&S  Policy  Documents 

The  following  types  of  interoperability  policy 
elements  were  found  to  be  missing  from  interop¬ 
erability  policy  directives  in  both  domains: 

□  Technology  Integration 

□  Simulation  Based  Acquisition  (SBA) 

□  Formal  Interoperability  Theory  and 
Modeling 

□  Interoperability  Performance  measure¬ 
ment  and  standards 

2.8.5  Interoperability  Policy  Consistency 

Quantified  interoperability  performance  meas¬ 
ures  and  metrics  are  not  available  in  either  the 
C4ISR  or  M&S  domains.  It  is,  therefore, 
impossible  to  measure  and  compare  inter¬ 
operability  performance  in  either  domain;  and 


the  effects  of  changes  to  interoperability  policy 
can  never  be  known  or  understood.  C4ISR 
inter-operability  policy  defines  detailed,  explicit 
processes  and  procedures  for  achieving  C4ISR 
system  interoperability,  but  M&S  policy 
generally  does  not. 

3.  C4ISR-to-Simulation  FOMs 

This  section  includes  a  general  discussion  of 
C4ISR  FOMs  under  development,  and  their 
impact  on  M&S-to-C4I  interoperability.  (A 
copy  of  each  FOM  is  available  for  download  at 
http://www.sisostds.org/doclib/cat  display.cfm?i 

d  number-48.) 

3.1  A  Prototype  C4I  FOM 

The  Prototype  C4I  FOM  is  the  result  of  a  U.S. 
Army  requirement  to  develop  a  common 
environment  to  facilitate  the  use  of  constructive, 
virtual,  and  live  simulations  in  the  evaluation  of 
C4I  systems  in  the  Research,  Development,  and 
Acquisition  (RDA),  the  Advanced  Concepts  and 
Requirements  (ACR),  and  the  Training, 
Exercises,  and  Military  Operations  (TEMO) 
domains.  To  be  effective,  the  simulation 
environment  must  be  capable  of  interoperating 
with  real  C4I  systems  in  a  manner  that  is 
flexible,  extensible,  and  promotes  re-use  of 
software  components.  The  prototype  C4I  FOM 
is  a  step  toward  providing  this  capability  by 
providing  a  standardized  representation  for 
interoperability  that  can  be  applied  to  a  variety 
of  C4I  systems. 

The  feasibility  of  the  FOM  to  support  this  kind 
of  objective  simulation  environment  is  currently 
being  demonstrated  through  an  effort  to 
transition  the  TIM  to  the  HLA.  A  subset  of  the 
prototype  C4I  FOM,  plus  additional  domain- 
specific  classes  and  attributes,  has  been  used  as 
the  instantiation  of  the  FOM  for  the  TIM 
environment.  The  TIM  environment  provides  a 
realistic  interface  to  the  virtual  world  for  the 
Army’s  battalion  and  below  C2  system,  FBCB2. 

In  developing  the  initial  version  of  the  prototype 
C4I  FOM,  object-oriented  techniques  were  used 
to  gather  requirements,  synthesize  the  results, 
and  map  this  information  into  a  HLA  FOM 
representation.  An  Object-Oriented  Analysis 
(OOA)  and  an  Object-Oriented  Design  (OOD) 


methodology  was  used  to  generate  successive 
layers  of  increasing  detail,  allowing  for  the 
capture  of  many  of  the  details  of  the  problem 
domain.  The  information  was  specified  in  a 
manner  prescribed  by  the  HLA  Object  Model 
Template  (OMT).  Through  this  process  certain 
key  areas  were  identified  including  C4I  Systems, 
Communications  Device,  Communications 
Network,  Communications  Effects,  and 
Messages.  Initially  the  FOM  was  focused  on 
Army  lower  echelon  (battalion  and  below) 
exchange  of  Situation  Awareness  (SA)  and 
battle  command  messages  through  their  C2 
systems.  Included  in  the  FOM  were  the 
specification  of  the  various  categories  of 
communications  equipment  used  (radios, 
routers,  controllers),  configuration  of  the 
networks  (platoon,  company,  and  battalion  level 
networks),  and  the  effects  on  data  transmission 
resulting  from  the  combination  of  environmental 
factors,  network  latency  and  traffic  loading,  and 
characteristics  of  the  radio.  As  work  on  this 
effort  continues  during  Fiscal-Year  2000 
(FY00),  the  scope  of  the  FOM  will  evolve  to 
include  to  some  extent  higher  echelons  (i.e., 
brigade  and  division),  Information  Operations 
(IO),  intelligence,  and  sensors.  The  current 
version  of  the  prototype  C4I  FOM  is  available 
for  viewing  at  the  following  SISO  C4I  Study 
Groups  Document  Fibrary: 

http://www.sisostds.org/doclib/  index. cfm. 

3.2  TSIUFOM 

The  SMDC,  Exercises  and  Training  Division,  is 
developing  an  HLA  compliant  version  of  the 
TSIU.  The  TSIU  provides  a  data  interface 
between  the  virtual  simulation  environment  and 
the  Army  Battle  Command  System  (ABCS). 

The  concept  of  the  TSIU  is  to  translate  the 
simulation  update  data  into  the  appropriate 
tactical  format  for  transmission  to  tactical 
C4ISR  systems.  Historically  the  TSIU  has 
received  the  simulation  data  via  a  predefined  set 
of  message  updates  utilizing  a  DIS 
Transmitter/Signal  PDU  implementation.  The 
information  from  the  simulation  network  is 
translated  and  formatted  by  the  TSIU  and  then 
transmitted  on  a  separate  tactical  network  to 
linked  C4ISR  systems.  The  TSIU  provides  all 
message  formatting  capability,  therefore 
eliminating  the  requirement  for  participating 
simulations  to  maintain  the  ever-evolving 


tactical  message  format  specifications. 
Following  the  modeling  and  simulation 
community’s  migration  to  the  HLA,  the  TSIU 
program  has  recently  implemented  a  prototype 
C4ISR  FOM  to  achieve  a  working  HLA 
interface  to  the  simulation  environment. 

Building  on  previous  simulation  integration 
experience,  the  TSIU  C4ISR  FOM  incorporates 
many  of  the  data  elements  defined  by  the 
original  simulation  message  set.  The  simulation 
updates,  modeled  exclusively  as  non-persistent 
HLA  interactions,  are  defined  by  category  and 
support  a  variety  of  tactical  message 
classifications  including  Maneuver,  Intelligence, 
Air  Defense,  Fire  Support,  and  Combat  Service 
Support.  The  specific  interaction  parameters  are 
defined  to  a  level  of  detail  that  supports  efficient 
object  model  expandability  and  general 
readability.  In  addition  to  the  C4ISR  FOM 
development,  the  TSIU  has  incorporated  a  FOM 
mapping  capability,  which  will  allow  the  TSIU 
to  seamlessly  integrate  with  other  HLA  FOMs, 
as  future  exercises  require.  Currently,  the  TSIU 
has  successfully  integrated  with  SMDC's 
Extended  Air  Defense  Simulation  (EADSIM) 
using  the  TSIU  C4ISR  FOM.  Recent  tests  have 
included  the  TSIU  receiving  maneuver  and 
intelligence  interaction  updates  from  EADSIM 
and  using  the  interaction  data  to  generate  and 
transmit  tactical  messages  to  networked  C4ISR 
systems. 

3.3  J6  NETWARS  FOM 

Network  Warfare  Simulation  (NETWARS)  is  a 
Joint  Chief  of  Staff  modeling  and  simulation 
initiative  that  has  three  objectives: 

□  Perform  communication  burden 
assessment  for  a  Joint  Task  Force 
(JTF), 

□  Analyze  operational  communication 
plans,  and 

□  Assess  performance  impact  of  new 
technology  on  JTF  performance. 

The  underlying  principle  of  NETWARS  is  the 
development  of  standard  models  that  enhance 
interoperability  and  re-usability.  The 

NETWARS  modeling  standard  defines  class 
structures  from  which  a  minimum  set  of 
essential  attributes  is  defined.  For  example,  the 
radio  class  has  transmission  rate,  power,  and 


modulation  as  its  minimum  set  of  attributes. 
The  standard  would  also  provide  a  common 
naming  convention  to  facilitate  NETWARS 
interface  with  other  models.  Hence,  a 

developer  would  use  the  minimum  set  of 
attributes  and  would  parameterize  these 
attributes  appropriately  when  modeling  a 
specific  radio. 

The  NETWARS  FOM  is  based  on  this  class 
definition  and  essential  set  of  attributes. 
Depending  on  the  type  of  models  that  are  to  be 
federated  with  NETWARS,  this  FOM  provides 
the  necessary  information  to  enhance  the 
probability  of  success  when  it  is  required  to 
federate  with  other  modeling  environments. 

3.4  DII  COE  C4I  FOM  and  the  C4I 
Ambassador 

The  Naval  Research  Laboratory  is  developing  a 
C4ISR  FOM  for  DII  COE  based  C4ISR  systems 
under  the  sponsorship  of  DMSO  and  DISA. 

The  C4I  Ambassador  software  provides  two-way 
links  between  the  embedded  RTI  and  the  DII 
COE  Services,  data  bases  and  C4ISR  Mission 
Applications.  It  interprets  the  FOM  (parses  and 
reformats  data  as  necessary)  and  manages 
simulated  data  distribution  within  C4ISR.  This 
development  builds  on  the  technology  contained 
within  the  recently  released  Global  Command 
and  Control  System  (GCCS)  Embedded 
Training  Segments  for  inserting  training  data 
into  operational  GCCS  systems. 

3.4.1  Purpose 

The  (DII  COE)  C4I  FOM  and  the  C4I 
Ambassador  are  developed  to  embed  the  RTI 
and  all  necessary  software  within  C4ISR 
systems  to  allow  them  to  function  as  Federates 
within  an  HLA  Federation.  The  resulting  C4ISR 
Federates  provide  the  following  interoperability 
functionality: 

□  Facilitates  two-way  interactions 
between  C4ISR  systems  and 
simulations. 

□  Allows  multiple,  simultaneous 
Federates  on  a  single  C4ISR  LAN. 

□  Provides  both  database-to-database  and 
message  based  transactions. 


□  Processes  real-time,  faster  than  real¬ 
time  and  slower  than  real-time 
simulated  data. 

□  Ensures  C4ISR  mission  applications 
relate  the  same  way  to  simulated  and 
real  C4ISR  data. 

□  Allows  C4ISR  Federates  to  reside  and 
function  within  operational  C4ISR 
without  disrupting  real  world 
operations. 

3.4.2  DII  COE  C4I  FOM  General 

Characteristics 

The  C4I  FOM  work  originally  began  as  the 
Simulation-C4I  interface  used  in  Synthetic 
Theater  of  War  (STOW)  97  and  98  Exercises.  It 
has  progressed  to  be  used  for  the  Joint  Theater 
Level  System  (JTLS)  -  GCCS  Federation  and 
the  Naval  Simulation  System  -  GCCS/Maritime 
Federation.  Work  is  underway  to  incorporate 
this  technology  into  the  Navy  Modeling  and 
Simulation  Management  Office’s  Embedded 
Simulation  Infrastructure  Program  to  move 
simulations  into  GCCS/Maritime  and  the  COE. 
Subsets  of  the  overall  C4I  FOM  are  based  on 
standard  military  messages,  database  to  database 
transactions  and  the  Real  Time  Performance 
Reference  FOM  (RPR  FOM). 

Database-to-database  transactions  yield  the 
highest  level  of  interoperability  potential.  The 
FOM  design  approach  for  this  subset  is  to  define 
additional  objects  and  transactions  for  each  new 
federation  in  such  a  way  that  it  is  consistent 
with  C4ISR  data  content  and  internal  database 
organization.  The  objects  defined  to  date  are 
generally  associated  with  military  platforms  and 
units.  The  C4I  FOM  is  composed  of  objects  that 
directly  represent  the  Platform  and  Unit  objects 
stored  in  the  DII  COE  Tactical  Database 
Manager  (TDBM). 

There  are  also  interactions  in  the  FOM  that  are 
used  to  send  platform  position  change  requests 
(indirect  control)  to  the  simulation.  These 
interactions  are  modeled  after  routinely 
broadcast  real  world  orders  such  as  PIM  Track, 
Screen  Kilo  and  Four  Whiskey  Grid.  In 
addition,  DII  COE  Federates  have  object 
ownership  capabilities  and  the  C4I  FOM  defines 
the  means  for  C4ISR  to  initialize  scenarios, 
provide  updates  on  real  track  behaviors,  and 
control  forces  during  exercises  (for  those 


simulations  capable  of  supporting)  these 
interactions. 

3.5  Simulation-Based  C2  Integration 
Framework 

A  team  of  researchers  at  the  U.S.  Air  Force 
Electronic  Systems  Center  (ESC)  recently 
completed  a  prototype  featuring  Airborne 
Warning  and  Control  System  (AWACS)-related 
software  applications  operating  within  a 
simulated  battle.  This  effort  represents  a  first 
step  toward  a  Simulation-Based  C2  Integration 
Framework  (SBCIF)  for  testing  C2  system 
interoperability  as  MITRE  and  ESC  team  to 
migrate  existing  Air  Force  systems  to  the 
Integrated  C2  System  (IC2S). 

MITRE  internal  research  in  Simulation  to  C2 
System  Infrastructure  is  investigating 
technologies,  tools,  and  interface  approaches 
necessary  to  make  the  SBCIF  vision  a  reality. 
With  the  trend  in  modern  warfighting  toward 
increased  C2  system  interoperability,  system- 
specific  test  harnesses  traditionally  used  to 
exercise  stovepiped  C2  systems  will  no  longer 
suffice.  Instead,  a  synthetic  battlespace  is 
needed  that  provides  a  more  comprehensive, 
interactive  battle  environment  within  which  C2 
systems  can  refine  information  exchange 
mechanisms  and  processes. 

The  synthetic  battlespace  within  the  SBCIF  will 
be  composed  of  existing  simulations  connected 
via  the  HLA.  C2  systems  that  have  an  HLA 
interface  capability  will  be  able  to  take 
advantage  of  the  SBCIF  to  exercise  data 
exchange  capabilities  within  a  realistic  battle 
environment. 

In  the  AW  ACS  prototype,  the  battle  is  “fought'’ 
by  a  mission-level  battle  simulation.  As  the 
battle  plays  out  in  real  time,  information  about 
airborne  platforms  is  pumped  over  a  High  Level 
Architecture  (HLA)  Runtime  Infrastructure 
(RTI)  to  a  real-time  CORBA-based  AWACS 
infrastructure.  There  the  data  is  parceled  off  to 
AWACS-related  applications  for  processing  and 
display. 

The  AWACS  effort  demonstrates  the  potential 
of  the  HLA  as  a  mechanism  for  driving  real¬ 
time  C2  systems  with  simulated  battle  data  for 


testing,  experimentation,  training,  and  other 
purposes.  With  this  prototype  AWACS  becomes 
the  first  ESC  system  to  achieve  an  HLA 
connection  to  the  SBCIF.  Fully  realized,  the 
SBCIF  will  offer  a  wide  variety  of  C2  systems 
the  opportunity  to  take  advantage  of  an  HLA- 
based  synthetic  battlespace  to  refine  operational 
C2  capabilities. 

3.6  Joint  Theater  Level  Simulation  (JTLS)  - 
GCCS-NATO  C2  Federation 

The  JTLS-GCCS-NATO  C2  federation  was 
developed  to  examine  the  use  of  the  HLA  to 
build  interfaces  between  C2  systems  and 
simulations.  The  federation  comprises  a  set  of 
multinational  command  and  control  systems 
(GCCS  and  the  NATO  Consultation,  Command 
and  Control  Agency’s  (NC3A)  ICC  Air  Track 
display)  and  exercise  support  tools,  stimulated 
by  JTLS.  The  federation  is  a  partnership  of 
three  organizations,  the  DISA,  the  U.S.  Joint 
Forces  Command  Joint  Warfighting  Center 
(US  JFCOM/JWFC ),  and  NC3A.  Each 
organization  has  a  vested  interest  in  finding 
affordable  and  extensible  approaches  to  the  task 
of  linking  combat  simulations  to  fielded  C2 
systems  to  support  training.  DMSO  joins  the 
partnership  to  provide  the  HLA.  the  enabling 
technology  that  serves  as  the  foundation  for 
linking  C2  systems  to  simulations. 

3.6.1  Federates 

The  JTLS  Combat  Events  Program  (CEP)  is  the 
core  process  of  JTLS.  The  CEP  does  all  the 
modeling  of  the  combat  units,  the  events,  and 
the  battlefield  environment.  It  contains  the 
algorithms  for  computing  the  state  of  simulation 
objects,  and  reacts  to  orders  created  by  human 
operators  (players). 

GDS,  the  G-Protocol  Data  Server  (also  called 
the  Genis  Data  Server),  is  used  as  the  data 
management  and  distribution  component  of  the 
JTLS  system.  The  CEP  sends  state  information 
for  all  simulation  objects  to  the  GDS.  The  GDS, 
in  turn,  services  the  information  needs  of  an 
array  of  simulation  “clients,”  including  player 
consoles,  data  display  terminals,  and  data 
translation  modules  that  enable  linkage  to 
C4ISR  systems. 


The  Global  Command  and  Control  System 
(GCCS)  is  the  battlefield  situation  display  and 
information  management  system  for  theater  and 
joint  task  force  level  commanders  and  their 
staffs. 

The  NC3A  Order  Translation  Modules  (OTMs) 
are  a  response-cell  support  tool  that  enables  role 
players  to  enter  mission  orders  using  more 
"natural'’  operational  terms  and  graphics.  The 
OTMs  then  transform  this  data  into  a  set  of 
orders  for  subordinate  units  that  can  be  executed 
in  JTLS.  The  three  OTMs  that  are  included  in 
the  federation  represent  land  (LOTM),  naval 
(NOTM),  and  air  (OTMA)  functionality. 

The  NC3A  Aggregator  is  a  response-cell  tool 
intended  to  reduce  the  role  players'  workload  by 
making  it  easier  to  discover  and  report  status 
information  for  aggregate  units  (made  up  of 
several  smaller  sized  units  that  are  explicitly 
modeled  in  the  JTLS  game).  The  aggregator 
calculates  the  status  information  for  an 
aggregate  unit  from  the  data  for  the  individual 
constituent  units. 

The  NC3A  ICC  Air  Track  Formatter  is  a 
software  module  that  takes  simulation  state  data 
for  aircraft,  air  missions,  airbases,  SAM  sites, 
and  radar  sites  as  input  and  generates  output  in 
the  appropriate  format  for  several  NATO  C4ISR 
devices,  including  OPUS,  ACBA,  and  ICC. 

The  NC3A  Bi-MNC  Report  Generator  is  a 
family  of  processes  that  translate  a  subset  of 
JTLS  simulation  data  into  well-structured, 
formatted  NATO  messages.  These  messages 
can  then  be  delivered  to  the  training  audience 
via  real-world  communications  systems.  The 
modules  accomplish  the  end-to-end  process  of 
preparing  and  injecting  the  reports  into  the 
communications  backbone. 

3.6.2  1999  Federation  Activities 

During  1999,  the  federation  team  worked 
toward  the  goal  of  transitioning  the  federation  to 
the  JWFC  and  NC3A  for  use  in  computer-aided 
exercises.  The  JTLS  team  re-designed  and  re¬ 
implemented  the  RTI  interface  module  to 
improve  stability  and  performance  during 
federation  execution.  The  GCCS  team 
experimented  with  the  implementation  of  a  two- 
way  data  flow,  allowing  naval  orders  to  be  sent 


from  the  GCCS  workstation  to  the  JTLS.  The 
NC3A  team  added  two  new  federates,  the  Air 
and  Naval  Order  Translation  Modules  (OTMs), 
to  improve  usability  of  the  federation  during 
exercises.  Finally,  extensive  testing  during  the 
year  helped  to  improve  the  performance  and 
reliability  of  the  federation  with  large  exercise- 
level  scenarios. 

3.6.3  2000  Federation  Activities 

Immediate  objectives  for  the  federation  are  to 
finalize  the  transition  from  the  laboratory  to 
operational  exercises.  In  the  spring  of  2000, 
NC3A  deployed  the  federation  in  the  first  of 
several  NATO  exercises.  In  addition,  the  JWFC 
is  also  examining  potential  applications  of  the 
federation  later  in  2000.  Both  events  will 
warrant  continued  testing  with  an  emphasis  on 
improving  reliability,  performance,  and 
developing  a  better  understanding  the  potential 
uses  of  the  federation  in  an  exercise.  Other 
HLA  tools  that  would  be  new  federates  are 
under  evaluation  as  aids  for  monitoring  the 
federation  and  collecting  data  during  execution. 

3.7  Intelligence,  Surveillance,  and 
Reconnaissance  (ISR)  Analysis  FOM 

The  ISR  FOM  was  developed  to  support  the 
linkage  of  legacy  and  newly  developed  federates 
into  an  analysis  federation.  This  analysis 
federation  is  intended  to  support  the  various, 
regularly  occurring  DoD  and  Intelligence 
Community  studies  that  have  a  need  to  be  able 
to  analyze  the  impact  of  intelligence 
community-derived  information  upon  the  battle 
in  terms  of  quality,  quantity,  and  timeliness  of 
related  products. 

This  ISR  FOM  breaks  out  the  various  aspects  of 
the  intelligence  cycle,  and  subdivides  each  into 
its  respective  subordinate  detailed  processes.  As 
such,  this  ISR  FOM  provides  a  taxonomy  for  the 
overall  intelligence  cycle,  to  include  the 
following: 

□  Requirement/Concept  of  Operations 
(CONOPS)  Analysis  and  Generation; 

□  Mission  Planning; 

□  ISR  Sensor  Collection; 

□  Tasking,  Processing,  Exploitation  and 
Dissemination  (TPED);  and 

□  Ground  Truth. 


3.8  FOM  Alignment  Summary 

The  FOMs  reported  in  the  previous  sections  are 
potential  sources  of  standard  objects  and 
interactions.  However,  it  is  essential  that  first 
these  FOMs  be  consistent  among  themselves. 
Here,  we  discuss  how  two  of  these  FOMs  are 
being,  or  can  be  aligned,  to  provide  such 
consistency  under  an  umbrella  of  a  hypothetical 
SISO  C4ISR  FOM.  This  “FOM”  would  then 
provide  quasi-standards,  or  recommended 
elements,  that  would  facilitate  the  use  of  real 
systems  in  constructive,  virtual,  and  live 
simulations. 

The  Prototype  C4ISR  FOM  discussed  in  Section 
3.1  provides  a  good  starting  point  in  discussing 
current  and  future  FOM  alignment.  To  begin 
with,  this  FOM  uses  the  RPR  FOM  BaseEntity 
class  hierarchy,  with  certain  modifications.  As 
shown  in  its  Object  Model  Identification  Table, 
the  developers  added  a  CommUser  class,  an  IW 
Effects  hierarchy,  and  an  updated  C4IDevice 
hierarchy,  adding  various  attributes  to  existing 
classes  and  deleting  extraneous 
ENUMERATIONS  inherited  from  the  RPR 
FOM.  This  provides  a  broad-based  commonality 
for  any  FOM  that  leverages  off  or  aligns  with 


this  C4I  FOM.  With  a  goal  of  general  alignment 
among  C4I  FOMs,  the  C4I  FOM  developers  and 
the  J6  NETWARS  FOM  developers  have 
engaged  in  an  effort  to  align  matching  elements 
of  these  two  FOMs.  For  example,  under 
examination  it  was  found  that  both  FOMs  had 
defined  similar  variables  albeit  not  always  with 
the  same  names.  The  following  Table  shows 
some  of  the  observed  alignment. 


Prototype  C4I  FOM 

NETWARS  FOM 

Antenna 

Antenna 

CommLink 

Communications  Link 

EndUserSystem 

End_System 

NetworkDevice 

Networking_Equipment 

However,  there  are  several  cases  where  each 
FOM  defines  a  variable  not  defined  in  the  other 
FOM.  For  example,  the  NETWARS  FOM 
defines  the  variables  ATM_Device,  Satellite, 
and  Hybrid_Model  which  were  not  initially 
defined  by  the  C4I  FOM.  Further  effort  on  the 
alignment  of  these  FOMs  will  be  required  for 
either  of  these  FOMs  to  approach  RFOM  status 
and  to  fit  within  the  umbrella  of  the  C4ISR 
FOM. 


W  here  we  are  now  and  where  we  need  to  go  / 
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Figure  6.  The  Road  Ahead 


In  summary,  we  have  seen  the  beginning  of 
FOM  alignment  in  the  collaboration  of  the 
prototype  C4I  FOM  and  NETWARS  FOM 
developers.  Lessons  learned  during  the  FOM 
alignment  positively  reinforce  common  design 
approaches,  criteria,  and  detail.  Alignment  of 
other  FOMs  will  increase  the  general 
applicability  of  the  C4ISR  FOM,  create  buy  in  of 
multiple  potential  FOM  users  and  increase  the 
FOMs  critical  mass  required  for  Reference  FOM 
status. 

4.  Vision 

Our  roadmap  for  improving  the  interoperability 
between  simulations  and  C4I  systems  is  shown 
in  Figure  6  and  our  vision  of  an  interoperable 
M&S-to-C4I  framework  is  shown  in  Figure  7. 

For  the  near  term.  Figure  6  depicts  the  currently 
predominant  architectures  in  use  for  M&S-to- 
C4I  interfaces.  Such  interfaces  are  mostly 
custom  “point-to-point”  links  that  are  often 
“black  box”  in  nature.  Simulation  control  is 


basically  one-way,  with  the  simulations 
initializing  the  real  C4ISR  system  databases. 

In  the  mid  term,  we  expect  to  see  the  HLA 
linking  constructive  and  virtual  simulations  on 
the  simulation  side  and,  on  the  “real”  side,  the 
HLA,  via  common  components  found  in  C4ISR 
systems  (e.g.,  the  DII  COE  Common  Message 
Processor)  also  allowing  C4ISR  systems  to 
exchange  both  data  and  messages  with 
simulations.  Simulation  initialization  will  be 
two-way,  with  real  system  databases  providing 
information  to  the  simulation  side. 

Ultimately,  as  shown  as  “ Far  Term,”  we  expect 
to  have  full  two-way  linkages  via  common 
databases,  thus  achieving  a  higher  measure  of 
interoperability.  As  one  would  expect,  Figure  6 
articulates  only  a  broad  vision  of  where  M&S- 
to-C4ISR  interoperability  needs  migrate  to  go 
over  time.  The  Far  Term  is  not  an  end  state,  but 
“is  where  we  could  be  in  2010  to  2012,  if  we 
[the  M&S  and  C4ISR  communities ]  articulate 
our  [joint]  requirements  and  develop 
coordinated  architectures  and  standards”  [28]. 
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Figure  7.  An  Interoperable  M&S  and  C4ISR  Framework 


The  figure  is  not  meant  to  imply  that  C4ISR 
systems  have  never  been  linked  with  live 
components  (i.e.,  tanks  and  infantry  fighting 
vehicles),  but  that  it  is  only  in  the  far  term  that 
we  expect  “to  see  substantial  progress  in 
constructing  common  interfaces  to  live 
equipment  such  as  weapons  platforms”  [28]. 

Finally,  Figure  7  depicts  our  vision  of  an 
interoperable  M&S  and  C4ISR  framework 
where  interoperability  is  based  on  a  common 
conceptual  reference  model  accommodating 
common  C4ISR  component  interfaces,  common 
standards  and  tools,  and  aligned  architectures, 
all  linked  via  a  common  information 
management  process  to  provide  common,  shared 
solutions  for  the  C4ISR  and  simulation 
communities. 


Whereas  Figure  6  projects  change  over  time  and 
lists  some  of  the  components  and  elements  that 
must  result  or  support  that  change.  Figure  7 
focuses  on  the  concept  of  a  comprehensive 
collection  of  interdependent  efforts  that  must  be 
addressed  in  parallel  in  order  to  achieve 
interoperability. 

Standards  play  a  major  role  in  interoperable 
systems  and  are  focused  primarily  in  the  bottom 
three  blocks  of  Figure  7.  The  SIW  C4I  Forum 
should  focus  its  efforts  on  “Alignment  of 
Architectures,”  “Common  Data/Objects,”  and 
“Common  Standards  &  Tools.”  It  must  be 
understood  that  a  set  of  processes  -  “Processes 
For  Alignment  &  Migration”  -  executed  by  both 
M&S  and  C4ISR  agencies  (e.g..  DMSO  and  the 
Defense  Information  Systems  Agency)  must 
accompany  the  standards  efforts  to  effect  the 


change  required  for  true  M&S-to-C4I 
interoperability. 

4.1  Towards  M&S-to-C4I  Data  Alignment 
and  Interoperability 

This  sub-section  presents  a  C4I/M&S  Technical 
Reference  Model  (TRM)  for  a  complete  C4ISR 
to  simulation  interface  and  also  functional 
requirements  for  such  an  interface.  This 
discussion  will  set  the  stage  for  the  subsequent 
sections,  and  is  intended  to  identify  the 
information  needed  when  interfacing  systems 
from  the  M&S  and  C4ISR  domains. 

To  be  specific,  TRM  is  “a  conceptual 
framework”  that  provides  the  following: 

□  A  consistent  set  of  service  and  interface 
categories  and  relationships  used  to 
address  interoperability  and  open- 
system  issues 

□  Conceptual  entities  that  establish  a 
common  vocabulary  to  better  describe, 
compare,  and  contrast  systems  and 
components 

□  A  basis  (an  aid)  for  the  identification, 
comparison,  and  selection  of  existing 
and  emerging  standards  and  their 
relationships  [11]. 

4.1.1  Information  Exchange  Requirements 

Prior  to  discussing  specific  standard  software 
components  and  data  models,  it  is  desirable  first 
to  identify  and  classify  the  information  that  must 
flow  between  M&S  and  C4ISR  systems.  This 
will  not  be  possible  until  there  is  a  common 
understanding  of  what  constitutes 
interoperability  and  the  identification  of  one  or 
more  technical  reference  frameworks.  Second, 
in  order  for  M&S  developers  to  build  internal 
interface  features  that  will  work  across  a  C4ISR 
domain  (and  C4ISR  developers  to  build  in  M&S 
features)  the  different  types  of  information  need 
to  be  standardized  to  some  extent.  DIFs  such  as 
the  Command  and  Control  Simulation  Interface 
Language  (CCSIL)  [32]  need  to  be  created  for 
specific  information  classes.  We  identify  here 
three  broad  classes  that  are  necessary  to  meet 
conceptual  requirements  that  would  result  in 
improved  interoperability: 

□  Persistent  Data 


□  Non-Persistent  Data 

□  Execution  Control 

Persistent  Data  refers  to  the  class  of  information 
that  is  stored  during  the  operation  of  the 
simulation.  Information  belonging  to  this  class 
is  typically  initialized  prior  to  execution  and 
changes  less  frequently,  during  simulation 
execution,  than  Non-Persistent  Data. 

Non-Persistent  Data  refers  to  the  class  of 
information  that  is  transient,  corresponding  to 
interactions  between  entities  or  objects  in  the 
simulation  or  C4ISR  database,  or  updates  to  an 
entity's  state. 

The  third  class  of  information  necessary  for  a 
complete  interface  is  Execution  Control. 
Simulations  typically  have  a  set  of  protocols  that 
allow  an  operator  to  control  the  simulation’s 
execution  and/or  synchronize  it  with  other 
simulations;  including  time  management 
functions.  Current  C4ISR  systems  do  not  have 
protocols  that  correspond  to  information  classes; 
however,  future  C4ISR  systems  must  have  such 
information  classes/protocols  to  enable  them  to 
be  fully  interoperable  with  simulations. 

One  example  of  this  latter  class  is  the 
requirement  for  After  Action  Review  (AAR). 
While  simulations  can  typically  replay  a 
scenario  that  had  previously  occurred,  it  is  often 
desirable  to  synchronize  C4ISR  systems  with 
this  playback  to  show  the  information  available 
for  decision  making  for  particular  events. 
Unless  these  requirements  are  specified  to 
C4ISR  developers,  C4ISR  systems  may  not  have 
a  capability  to  perform  such  operations. 

Birkel  [3]  has  developed  a  Synthetic  Natural 
Environment  (SNE)  Conceptual  Reference 
Model  that  is  very  similar  to  the  TRM  described 
here.  It  is  more  focused  on  environmental 
effects  but  still  is  oriented  towards  interfacing  to 
C4ISR  systems.  It  provides  an  excellent 
comparison  and  alternate  viewpoint  to  the  TRM. 
The  TRM  is  more  focused  on  information 
exchange,  while  the  SNE  Conceptual  Reference 
Model  is  more  focused  on  functionality.  The 
SNE  Conceptual  Reference  Model 
authoritatively  extends  the  description  of  those 
classes  in  the  TRM  that  deal  with  the 
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Figure  8.  A  C4I/M&S  Technical  Reference  Model 


environment  (interfacing  to  physical  and 
environmental  models  in  the  TRM). 

Others  have  proposed  models  of  C4I/M&S 
interoperability;  many  of  those  were  reviewed 
during  the  development  of  the  TRM  described 
here.  Layman  [29]  discusses  a  model  of  an 
interface  for  multi-level  team  training.  This 
model  divides  information  into  C2,  Tactical 
Communications,  Combat  Systems,  and  Sensors 
classes.  These  classes  all  fall  into  the  Non- 
Persistent  Data  category  in  the  proposed  model. 
Farinacci,  Roberts,  and  Winner  [15]  describe  an 
architecture  for  establishing  interoperability 
between  a  C4ISR  system  and  CGF  Simulation 
using  the  HLA. 

4.1.2  C4I/M&S  Technical  Reference  Model 

Figure  8  shows  a  notional  Computer  Generated 
Forces  (CGF)  simulation  with  the  types  of 
information  that  a  complete  interface  must 
accommodate.  The  interface  design  is  not 

specified.  The  function  of  the  interface  is  to  1) 
control  the  information  flow  between  the  C4ISR 


system  and  the  simulations  and  2)  to  align  the 
information  among  the  systems  so  that  the 
information  is  received  in  a  system’s  native 
format.  Note  that  all  of  the  information  may 
flow  bi-directionally.  Thus  M&S  systems  would 
need  to  have  the  capability  built  to  accept 
initialization  data  and  orders  from  C4ISR 
systems,  as  well  as  being  able  to  pass  scenario 
initialization  data  and  messages  to  C4ISR 
systems. 

The  notional  CGF  can  be  thought  of  as  an 
example  of  a  current  generation  object-oriented 
simulation,  having  different  modules  for 
Exercise  Control,  Behaviors,  Environment,  and 
Physical  Models  tied  together  with  a  Run  Time 
Framework.  Persistent  data  is  stored  in  a 
Scenario  Database.  Current  simulations,  such  as 
ModSAF  [7],  can  be  easily  mapped  to  this 
notional  CGF.  Each  of  the  12  separate 
information  types  is  a  candidate  for  a  separate 
Reference  Federation  Object  Model  (RFOM). 
Figure  8  depicts  several  other  specific  interface 
requirements: 


□  Exercise  Control  Interactions  are  a 

type  of  Execution  Control  that  is  passed 
to  control  the  conduct  of  an  event.  The 
controls  would  allow,  for  example, 
“checkpointing'’  of  both  simulations 
and  C4ISR  systems,  as  well  as  allowing 
pausing  of  the  C4ISR  system  at 
appropriate  points  in  the  exercise. 
Initialization  and  AAR  protocols  would 
also  fall  in  this  category.  Exercise 
Control  Interactions  would  be 
interfaced  to  an  Exercise  Control 
Module  of  a  simulation.  Logging  is 
explicitly  identified  as  a  separate 
category  due  to  the  importance  of  this 
function. 

□  Orders  are  a  type  of  interaction  that 
convey  C2  information.  Translation  of 
this  class  of  information  has  been 
extremely  difficult  to  achieve  with 
current  interfaces  [4],  Presently, 
C4ISR  systems  do  not  support  the 
generation  and  maintenance  of  this  C2 
information  in  a  uniform  manner. 

□  Reports  are  a  type  of  C2  information 

about  the  state  of  an  entity.  The 
majority  of  current  interfaces  deal  with 
this  class  of  situational  awareness 
information.  Typical  report 

information  includes  location  and 
status,  and  may  be  sent  to  the  C4ISR 
system  as  either  tactical  messages  or 
data  updates.  Both  Orders  and  Reports 
would  interface  to  Behavior  Models  of 
a  simulation,  affecting  the  decision 
making  of  simulated  units.  If  the 
simulation  offers  a  high  degree  of 
fidelity  in  C2,  it  may  associate  these 
interactions  with  Communication 
Effects. 

□  Imagery  is  a  type  of  unprocessed  visual 
C2  information  from  a  sensor.  This 
data  is  characterized  by  high  bandwidth 
requirements  and  the  need  to  be 
processed  or  analyzed  prior  to  use. 
Imagery  would  also  interface  to 
Behavior  Models  of  a  simulation, 
affecting  the  decision  making  of 
simulated  units.  Examples  of  this 
would  be  video  from  an  Unmanned 


Aerial  Vehicle  (UAV)  or  a  Moving 
Target  Indicator  (MTI)  radar  image 
from  a  Joint  Surveillance  and  Attack 
Radar  System  (JSTARS)  [56]. 

□  Track  Data  is  information  regarding 
the  physical  state  of  entities  (or 
objects).  This  class  of  information  also 
includes  physical  interactions  between 
objects  (such  as  weapon  effects).  A 
simulation  may  need  to  know  the 
location  of  a  live  unit,  even  if  it  is  not 
sending  out  report  messages  (Reports). 
Alternatively,  air  tracks  of  a  simulated 
aircraft  may  need  to  be  generated  for  a 
radar  screen.  If  the  data  passed  to  the 
interface  is  ground  truth,  then  the  data 
should  have  effects  applied  to  turn  the 
data  into  perceived  truth.  These 
interactions  would  be  processed  by  the 
Physical  Models  Module  of  a 
simulation. 

□  Communication  Effects  (CE)  emulate 
the  characteristics  of  the 
communications  channel  by  which  the 
information  in  classes  Orders  and 
Reports  are  passed  [6  &  42].  In  most 
cases,  a  CE  interaction  would  be  paired 
with  a  C2  interaction.  This  interaction 
would  be  interfaced  to  a  physical  device 
model  (such  as  a  radio  model)  that 
transmits  or  receives  the  CE 
interaction,  in  the  Physical  Models  of 
the  simulation. 

□  Persistent  Data  covers  a  wide  variety 
of  information.  This  usually  includes 
Order-of-Battle  (OB)  information  as 
well  as  specification  of  the  terrain  to  be 
used.  Typically  this  information  is  not 
exchanged  in  current  interfaces,  but 
rather  is  manually  aligned.  As  an 
example,  a  C4ISR  system  will  have  an 
OB  database,  and  a  simulation  will 
have  a  completely  different 
representation  of  these  units.  It  should 
be  possible  to  initialize  the  simulation 
from  a  C4ISR  system,  just  as  a  C4ISR 
system  should  be  able  to  be  populated 
with  exercise  data  from  a  simulation. 
Persistent  Data  would  be  initialized  at 
runtime  and  kept  current  during 


execution.  This  class  of  information 
would  interface  to  the  simulation’s 
Scenario  Database,  as  well  as  the 
Environmental  Models  Module  for 
dynamic  updates  during  execution. 
Persistent  Data  includes:  Weather  Data 

-  essential  for  training  exercises; 
Communications  Laydown  -  needed  for 
initializing  communications  networks 
so  that  communication  effects  can  be 
modeled;  Mission  and  Plan  information 

-  necessary  for  generation  of  orders; 
Unit  Data  -  including  the  OB  and 
associated  information;  and  Terrain 
Standards.  Interchange  of  terrain 
formats  has  been  problematic  within 
the  simulation  domain  as  well  as  within 
the  C4ISR  domain. 

4.2  Incorporating  Metadata 

The  proposed  technical  reference  model 
identifies  three  broad  classes  of  data.  The  lack 
of  a  fourth  class  of  orthogonal  data  inhibits  full 
interoperability.  Metadata,  or  data  about  the 
data,  is  needed.  The  M&S  community  and  the 
C4ISR  users  go  to  great  lengths  to  certify  their 
initial  databases.  Yet,  as  soon  as  interactive 
simulations  start,  data  changes.  Few  systems 
today  track  these  changes  in  detail.  Fewer  still 
report  these  changes  with  accompanying 
metadata  to  targeted  C4ISR  systems.  Without 
metadata,  subscribers  cannot  ensure  that  RTI 
data  originates  from  the  “correct”  source  within 
a  federation.  Without  metadata,  C4ISR  systems 
may  not  be  able  to  determine  where  the  data 
entered  the  system  and  who  within  the  system 
should  receive  it.  Moreover,  these  systems  may 
not  be  able  to  determine  priority  of  the  data  or 
the  very  nature  of  the  data  (simulation  data 
versus  real-world  information).  Thus,  metadata 
tags  must  record  state-of-the-world  information 
for  each  piece  of  critical  data.  These  data  items 
include,  but  are  not  limited  to,  authorized 
source(s),  version  numbers,  date  and  time, 
destination,  authenticated  observers,  etc. 

4.3  LISI  Model 

While  not  explicitly  developed  to  codify  cross¬ 
domain  links  to  M&S,  the  LISI  model  (Figure  1 ) 
provides  a  reasonable  framework  to  scope  the 


needed  level  of  connectivity.  In  general,  lower 
levels  of  interoperability  require  increased 
manual  intervention  to  maintain  links. 
However,  higher  levels  of  interoperability  are 
not  free.  In  general,  they  impose  requirements 
for  recurrent  coordination  between  independent 
programs,  increased  levels  of  engineering 
development,  and  robust  configuration 
management. 

LISI  identifies  four  domains:  Procedures  and 
Policy,  Applications,  Data,  and  Infrastructure 
(PAID)  which  impact  on  information  exchange. 
As  suggested  in  Figure  1,  a  level  of 
interoperability  exists  within  each  of  the  PAID 
domains.  Unfortunately,  the  interoperability 
achieved  between  two  systems  is  dependent  on 
the  lowest  level  attained  within  the  four 
domains.  Thus,  use  of  a  “sneaker  net”  to  pass 
information  between  systems  of  different 
security  levels  is  not  unusual,  even  though  the 
applications,  infrastructure  and  data  may  be 
common.  This  then  attests  to  the  impact  of  the 
lowest  domain  level  and  the  appropriateness  of 
considering  all  four  domains. 

Thus  far,  the  C4I/M&S  TRM  focuses  on  data 
exchanges.  As  the  LISI  model  suggests,  this 
inadequately  addresses  interoperability  between 
two  systems.  Given  the  LISI  model  was  not 
developed  to  classify  links  between  the  M&S 
and  C4ISR  domains,  these  connections  may 
drive  extensions  to  the  LISI  metric.  Potential 
expansion  of  LISI  warrants  further  study  by 
DMSO,  in  conjunction  with  DISA,  to  classify 
links  between  M&S  components  and  standard 
gateways.  Extension  should  allow  the  LISI 
model  to  fully  capture  potential  connections 
between  systems  built  to  common  standards. 

4.4  Communications  Interoperability 

Communications  is  often  treated  separately  in 
M&S-to-C4I  interoperability.  In  modeling 
communications  there  is  a  body  of  expertise 
separate  from  that  used  for  developing  interfaces 
to  C4ISR  systems.  In  addition,  many  current 
C4ISR  interfaces  do  not  include 
communications  considerations.  In  this  sub¬ 
section  we  discuss  three  different  aspects  related 
to  communications:  1 )  communications 

modeling;  2)  communications  effects;  and  3) 


communications  content.  Additional  issues 
associated  with  communication  interoperability 
include  system  and  simulation  interface 
anomalies  (induced  by  the  insertion  of 
simulations  into  the  C4ISR  architecture), 
fidelity,  and  connectivity  between  the  “real'’  and 
simulated  environments  (i.e.,  a  gateway  device). 

Communications  modeling  focuses  on 
representation  of  communications  elements  such 
as  communications  equipment,  traffic,  topology, 
and  protocols.  Typical  uses  include  the 
assessment  of  measures  of  performance,  such  as 
latency,  utilization,  throughput,  etc.  This  can  be 
accomplished  through  abstractions  of  the 
information  passed  between  C4ISR  systems  and 
networks.  Often  communications  is  not 
simulated  in  real  time.  Communications 
modeling  can  be  performed  with  or  without  an 
interface  to  C4ISR  systems  and/or  networks. 

Communications  effects  focus  on  the 
environment’s  impact  on  communications 
traffic.  For  example,  a  radio  transmission  may 
be  degraded  due  to  propagation  losses  resulting 
from  terrain  and  atmospheric  effects.  Other 
types  of  degradation  include  increased  latency 
due  to  network  loading  and  routing,  the 
characteristics  of  the  radio  (i.e.,  bit  error  rate  or 
the  radio’s  signal  to  noise  ratio),  and 
interference  and  jamming. 

Communications  content  of  the  information 
transaction  is  another  consideration  for 
communication  interoperability.  The  spectrum 
of  content  can  range  from  the  specific  size  or 
format  of  the  message  to  the  actual  message 
content.  For  example,  message  formats  for 
tactical  data  link  or  imagery  can  be  generated  by 
a  simulation  and  transmitted  to  a  C4ISR  system 
that  would,  in  real  life,  have  to  process  the 
information. 

5.  Recommendations 

Over  the  last  20  years  M&S  and  C4ISR  have 
been  linked  via: 

□  Standard  message  formats; 

□  Message  translation; 

□  Message  parsing  augmented  by 
database  mapping; 


□  Translation  of  C2  directives  (e.g.. 
Call  for  Fire)  into  simulation 
“orders”  (CCSIL);  and 

□  Data  replication. 

Obviously,  better  interoperability  standards 
between  M&S  and  C4ISR  systems  are  necessary, 
but  not  sufficient.  Both  simulations  and  C4ISR 
systems  must  increase  their  functional 
capabilities  [5],  For  example,  simulations  must 
improve  their  reporting  capabilities,  and  C4ISR 
systems  must  become  aware  of  simulation 
constructs  like  exercise  control. 

In  order  to  foster  better  understanding  between 
the  M&S  and  C4ISR  communities,  recommend 
that  the  SIW  C4ISR  Track  collaborate  with  the 
U.S.  Assistant  Secretary  for  Defense  for 
Command.  Control,  Communications,  and 
Intelligence  (ASD(C3I))  sponsored  Command 
and  Control  Research  and  Technology 
Symposium  to  help  further  M&S-to-C4I 
interoperability  and  to  investigate  joint 
standards  development. 

In  addition,  develop  a  set  of  SISO  M&S-to-C4I 
interoperability  “recommended  practices”  and/or 
standards  by: 

□  Creating  a  SISO  M&S-to-C4I 
Interoperability  TRM  from  the 
C4I/M&S  TRM  described  in  Section 
4.1.2.  This  TRM  should  include  a 
fourth  broad  data  class.  Metadata  as 
described  in  Section  4.2  and  consider 
the  LISI  model. 

□  Creating  a  SISO  guide  to  linking  M&S 
and  C4ISR  systems  via  standard 
message  formats,  data  replication,  etc. 

□  Using  both  the  Prototype  C4I  FOM 
described  in  Section  3.1  and  the  J6 
NETWARS  FOM  described  in  Section 
3.3  as  starting  points,  create  a  SISO 
C4I  Reference  FOM  that  provides  a 
framework  under  which  Base  Object 
Models  (BOM)  (e.g.,  a  radio  class)  can 
be  incorporated. 

6.  References 

[1]  Anderson,  J.R.,  Anderson,  T.,  and  Hardin, 
G.:  “The  Tactical  Simulation  Interface 
Unit  (TSIU)  Program,”  Paper  00F-SIW- 


046,  2000  Fall  Simulation  Interoperability 
Workshop,  2000. 

[2]  Brandt,  K.:  “Modeling  and  Simulation 
Links  with  Command  and  Control  (C2) 
Systems:  Considerations  in  Architecture 
Design,”  Paper  99F-SIW-181,  1999  Fall 
Simulation  Interoperability  Workshop, 
1999. 

[3]  Birkel,  P.:  “SNE  Conceptual  Reference 
Model,”  Paper  98F-SIW-018,  1998  Fall 
Simulation  Interoperability  Workshop, 
1998. 

[4]  Carr,  F.H.  and  Hieb,  M.R.:  “Issues  and 
Requirements  for  Future  C4ISR  and  M&S 
Interoperability,”  7th  Conference  on 
computer  Generated  Forces  and  Behavioral 
Representation,  1998. 

[5]  Carr,  F.H.  and  Hinton,  L.G.:  “Stimulating 
C4I  Systems  and  Achieving  Control  of  the 
Simulated  Battlefield,”  Paper  97F-SIW- 
136,  1997  Fall  Simulation  Interoperability 
Workshop,  1997. 

[6]  Carr,  F.H.  and  Roberts,  J.D., 

“Incorporating  Command  and  Control  into 
the  High  Level  Architecture:  An 

Architecture  for  Realistic  Communication 
Effects,”  Paper  97F-SIW-076,  1997  Fall 
Simulation  Interoperability  Workshop, 
1997. 

[7]  Ceranowicz,  A.:  “ModSAF  Capabilities,” 
4th  Conference  on  Computer  Generated 
Forces  and  Behavior  Representation,  1994. 

[8]  Christopherson,  T.  and  Dacunto,  L.J.: 
“Simulation,  Testing,  Operations, 
Rehearsal  Model  (STORM),”  Paper  98S- 
SIW-027,  Spring  1998  Simulation 
Interoperability  Workshop,  1998. 

[9]  Defense  Information  Infrastructure  (DII 
COE)  Architecture  Oversight  Charter, 
Office  of  the  Defense  Information  Systems 
Agency,  http://diicoe.disa.mil/coe/aog 
twg/aog/aog  page.html,  January,  1997. 

[10]  Department  of  Defense  (DoD)  5000. 59-P, 
DoD  Modeling  and  Simulation  Master 
Plan,  http://www.dmso.mil/documents/ 
policy/  msmp/index.html/,  1995. 

[11]  Department  of  Defense  (DoD),  DoD 
Technical  Reference  Model  Version  1.0, 
Defense  Information  Systems  Agency,  5 
November  1999,  http://www-trm.itsi.disa. 
mil. 

[12]  Defense  Modeling  and  Simulation  Office 
(DMSO)  Information  Paper,  “Conceptual 


Models  of  the  Mission  Space,” 
ftp://ftp.dmso.mil/pub/documents/initiative 

s/cmms/98s  siw  infoprp.pdf/,  1998. 

[13]  Defense  Modeling  and  Simulation  Office 
(DMSO)  Information  Paper,  “Conceptual 
Models  of  the  Mission  Space,” 
ftp://ftp.dmso.mil/pub/documents/initiative 

s/cmms/cmms  information  paper 

short.pdf,  1998. 

[14]  Loental.  D.  and  Leath,  R.:  Simulation  To 
C4I  Interface  (SIMCI)  Capstone 
Requirements  Document,  (Draft), 
TRADOC  Analysis  Center,  14  October 
1999. 

[15]  Farinacci,  M.I.,  Roberts,  J.D,  and  Winner, 

B.R.:  “Incorporating  Command  and 

Control  into  the  High  Level  Architecture,” 
Paper  96-15-021,  15th  Workshop  on  the 
Interoperability  of  Distributed  Interactive 
Simulations,  1996. 

[16]  Ferguson  P.  and  Huston,  G.:  “Quality  of 
Service:  Delivering  Quality  of  Service  on 
the  Internet  and  in  Corporate  Networks, 
John  Wiley  &  Son,  New  Your,  1998. 

[17]  Flournoy,  D.:  “Reconciling  Emerging 

Infrastructure  Standards  to  Promote  C2-to- 
Simulation  Interoperability,”  Paper  98F- 
SIW-027,  1998  Fall  Simulation 

Interoperability  Workshop,  1998. 

[18]  Hieb,  M.R.  and  Blalock,  J.:  “Data 

Alignment  between  Army  C4I  Databases 
and  Army  Simulations,”  Paper  99S-SIW- 
034,  1999  Spring  Simulation 

Interoperability  Workshop,  1999. 

[19]  Hieb,  M.R.,  Cosby,  M„  Griggs,  L„ 

McKenzie,  F.,  Tiernan,  T.,  and  Zeswitz, 
S.:  “MRCI:  Transcending  Barriers 

between  Live  Systems  and  Simulations,” 
Paper  97S-SIW-197,  1997  Spring 

Simulation  Interoperability  Workshop, 
1997. 

[20]  Hieb,  M.R.  and  Sprinkle,  R.:  “Simulation 

Infrastructure  for  the  DII  COE 
Architecture:  The  Army  Vision,”  Paper 
00F-SIW-035,  2000  Fall  Simulation 

Interoperability  Workshop,  2000. 

[21]  Hieb,  M.R.  and  Staver,  M.J.:  “The 
Army’s  Approach  to  Modeling  and 
Simulation  Standards  For  C4I  Interfaces,” 
Paper  98F-SIW-259,  1998  Fall  Simulation 
Interoperability  Workshop,  1998. 

[22]  Hieb,  M.R.  and  Timian,  D.H.:  “Using 
Army  Force-on-Force  Simulations  to 


Stimulate  C4I  Systems  for  Testing  and 
Experimentation,”  Paper  1999  Command 
and  Control  Research  and  Technology 
Symposium,  1999. 

[23]  Johnson,  T.H.:  “Mission  Space  Model 

Development,  Reuse,  and  the  Conceptual 
Models  of  the  Mission  Space  Toolset,” 
Paper  98S-SIW-155,  1998  Spring 

Simulation  Interoperability  Workshop, 
1998. 

[24]  Johnson,  T.H.  and  Might  R.J.: 

“Requirements  Analysis,  Mission  Space 
Models,  and  the  CMMS:  What’s  This  All 
About?,”  Article  Fall  1999  MSIAC  M&S 
Online  Journal,  http://www.msiac.dmso. 
mil/iournal/cmms.html/,  1999. 

[25]  Joint  Publication  1-02,  Department  of 

Defense  Dictionary  of  Military  and 

Associated  Terms,  June  14,  2000. 

[26]  Joint  Technical  Architecture,  Versions  1.0, 

2.0.  3.0,  and  3.1,  Defense  Information 
Systems  Agency,  http://www- 

jta.itsi.disa.mil,  3 1  March  2000. 

[27]  Krusche,  S.  and  Tolk,  A.:  “A  SHADE 
Approach  for  Coupling  C4I-Systems  and 
Simulation  Systems,”  Paper  99F-SIW-004, 
Fall  1999  Simulation  Interoperability 
Workshop,  1999. 

[28]  Lacetera,  J.  and  Timian,  D.H.:  “Interim 
Report  Out  of  the  C4I  Study  Group,”  Paper 
00S-SIW-060,  2000  Spring  Simulation 
Interoperability  Workshop,  2000. 

[29]  Layman,  G.E.,  Conover,  J.,  Kunkel,  P., 

and  Robins,  D.:  “JMCIS/GCCS 

Interoperability  with  External 

Simulations,”  Paper  97S-SIW-132,  1997 
Spring  Simulation  Interoperability 
Workshop,  1997. 

[30]  Legaspi,  A.K.  and  Ivancic,  C: 

“NETWARS  C4ISR  Communication 
Modeling  Standard,”  Paper  98F-SIW-017, 
2000  Fall  Simulation  Interoperability 
Workshop,  2000. 

[31]  Lightner,  M.,  Schanduaa,  J.,  Cutts,  D.,  and 

Zeswitz,  S.:  “The  High  Level  Architecture 
Command  and  Control  Experiment  - 
Lessons  Learned  in  Designing  an 

Extended  Federation,”  Paper  98S-SIW-93, 
1998  Spring  Simulation  Interoperability 
Workshop,  1997. 

[32]  MITRE:  1997  DARPA  CFOR/CCSIL  at 
http://ms.ie.org/cfor/,  1997. 

[33]  McConnell,  J.,  Riehl,  M.,  Hoang,  T., 
Tafoni,  T.,  and  Lacetera,  J.:  “A  Model  for 


Interfacing  a  C4I  System  to  Tactical 
Communications  Simulations,”  Paper  00F- 
SIW-064,  2000  Fall  Simulation 

Interoperability  Workshop,  2000. 

[34]  Menzler,  H.P.,  Krosta,  U.,  and  Pixius,  K.: 

“HLA  in  a  Nutshell:  Proposed  Standard 
Interface  for  Simulation,”  Paper  00S-SIW- 
026,  2000  Spring  Simulation 

Interoperability  Workshop,  2000. 

[35]  North  Atlantic  Treaty  Organization 
(NATO)  Document  AC/323  (SGMS)  D/2, 
NATO  Modelling  and  Simulation  Master 
Plan  (Version  1.0),  http://www.dmso.mil/ 
NATO  MSMP/msmp,  1998 

[36]  Newcomb,  M.,  Gustafson,  J.,  and  Nguyen, 

P.:  “The  WARSIM  C4I  Interface,”"Paper 
99F-SIW-036,  1999  Fall  Simulation 

Interoperability  Workshop,  1999. 

[37]  Ogren,  J.W.:  “Command  and  Staff 

Training  and  the  Practical  Use  of  the 
HLA,”  Paper  00F-SIW-061,  2000  Fall 
Simulation  Interoperability  Workshop, 
2000. 

[38]  Piece,  J.  and  Wood,  E.:  “The  TIM  Suite  - 
A  Federation  for  Live/Virtual  Simulation 
of  C4I  Systems,”  Paper  00F-SIW-066, 
2000  Fall  Simulation  Interoperability 
Workshop,  2000. 

[39]  Paola,  A.R.  and  Ressler,  R.L.: 

“Stimulating  the  Army  Tactical  Command 
and  Control  System  Using  the  Run  Time 
Manager:  Concepts  and  Implications,” 
Paper"  98S-SIW-162  1999  Spring 

Simulation  Interoperability  Workshop, 
1999. 

[40]  Ressler,  R.,  Hieb,  M.R.,  and  Sudnikovich, 
W.:  “M&S/C4ISR  Conceptual  Reference 
Model,”  Paper  99F-SIW-060,  1999  Fall 
Simulation  Interoperability  Workshop, 
1999. 

[41]  Shen,  B.,  Sudnikovich,  W.,  and  Kennedy, 

L. :  “Transition  to  The  Objective  C4I 
Modeling  and  Simulation  Environment,” 
ITSEC98,  December  1998. 

[42]  Silva,  W.  Steigerwald,  A.,  Cosby,  M.  Hieb, 

M. R.,  and  Lacetera,  J.:  “Communication 
Emulation  Design  in  the  MRCI  Program,” 
Paper  97F-SIW-160,  1997  Fall  Simulation 
Interoperability  Workshop,  1997. 

[43]  Simulations  Interoperability  Standards 
Organization  (SISO)  Command,  Control, 
Communications,  Computers,  and 
Intelligence  (C4I)  Study  Group  Terms  of 


Reference,  Vision, 

http://www.sisostds.org/  doclib/index.cfm. 

August  1999. 

[44]  Simulations  Interoperability  Standards 

Organization  (SISO)  Vision, 

http://www.sisostds.org/doclib/doclib.cfm? 

SISO  FID  2383,  May  5,  1999. 

[45]  Stanzione,  T.  and  Chamberlain,  F.: 
“Composable  Synthetic  Natural 
Environments  for  Computer  Generated 
Forces,”  7th  Conference  on  Computer 
Generated  Forces  and  Behavioral 
Representation,  1998. 

[46]  Sudnikovich,  W.  and  Roberts,  J.: 
“Implementation  of  a  prototype  C4I  FOM: 
Continued  Progress,”  Paper  99F-SIW-077, 
1999  Fall  Simulation  Interoperability 
Workshop,  1999. 

[47]  Sudnikovich,  W.,  Roberts,  J.,  and 

Lacetera,  J.:  “Implementation  of  a 

prototype  C4I  FOM,”  Paper  99S-SIW-061, 

1999  Spring  Simulation  Interoperability 
Workshop,  1999. 

[48]  Sutton,  P.W.:  “Interoperability  Policy 
Roadmap,”  Paper  00S-SIW-157,  Spring 

2000  Simulation  Interoperability 

Workshop,  2000. 

[49]  Thumim  K„  Clay,  B„  Hieb,  M.R.,  and 

Cosby,  M.:  “Modular  Reconfigurable 

Message  Translation:  Translation  of 

Messages  Between  C4I  Systems  and 
Simulations,”  Paper  97F-SIW-120,  1997 
Fall  Simulation  Interoperability  Workshop, 

1997. 

[50]  Timian,  D.H.:  Hicks,  M.W.,  and  Hieb, 
M.R.:  “An  Approach  for  Using  DII  COE 
Components  to  Fink  Simulations  and  C4I 
Systems:  A  Case  Study  Using  the  CMP,” 
Paper  00F-SIW-011,  2000  Fall  Simulation 
Interoperability  Workshop,  2000. 

[51]  Timian,  D.H.,  Hieb,  M.R.,  Glass,  J.,  and 

Staver,  M.J.:  “Using  Standard  C4I 

Components  to  Interface  to  Simulations,” 
Paper  98F-SIW-035,  1999  Spring 

Simulation  Interoperability  Workshop, 
1999. 

[52]  Tolk,  A.:  “HFA-OMT  versus  Traditional 
Data  and  Object  Modeling  -  Chance  or 
Shoehorn?,”  Paper  00S-SIW-024,  Spring 
2000  Simulation  Interoperability 
Workshop,  2000. 

[53]  Tolk,  A.:  “Requirements  for  Simulation 
Systems  when  being  used  as  Decision 


Support  Systems,”  Paper  99F-SIW-002, 

1999  Fall  Simulation  Interoperability 
Workshop,  1999. 

[54]  Tolk,  A.  and  Schiefenbusch,  K.: 
“Decision  Support  Systems  -  Concepts  and 
Effects,”  XXXVIII.  Army  Operations 
Research  Symposium,  1999. 

[55]  Wertman,  C.:  “History  and  Background  of 

C4I-to-Simulation  Interoperability,” 

C4ISR  Track  Invited  Speaker  Presentation, 

2000  Spring  Simulation  Interoperability 
Workshop,  2000. 

[56]  Williams,  M.:  “Proposal  for  Moving 
Target  Indicator  and  Synthetic  Aperture 
Radar  C4I  Imagery  Sensor  Federations  for 
HFA,”  Paper  98S-SIW-019,  1998  Spring 
Simulation  Interoperability  Workshop, 

1998. 

[57]  Yannni,  P.:  “A  VMF/Fink-16/ 

Simulation  Gateway;  Addressing  the 
Complexity  of  Datalink  Interoperability,” 
Paper  99S-SIW-068,  1999  Spring 

Simulation  Interoperability  Workshop, 

1999. 


7.  Acknowledgements 


While  the  authors  have  collated  submissions  and 
edited  this  report,  in  truth  it  is  the  result  of  more 
than  a  dozen  direct  contributions  in  the  form  of 
draft  sections  and  the  indirect  contributions  of 
the  more  than  one  hundred  subscribers  to  the 
SG-C4I  reflector.  Needless  to  say,  it  is 
impossible  to  thank  or  mention  all  of  the 
individuals  that  contributed  to  this  report. 
Nonetheless,  below  is  list  of  individuals  without 
whose  contributions  and  efforts  this  report 
would  have  impossible  to  write: 


Tonya  Anderson 
John  Bott 
Verlynda  Dobbs 
Doug  Flournoy 
Zach  Furness 
Carl  Ivancic 
Bob  Leath 
Dave  Loental 
Liesel  Muth 
Mary  Jean  Rackley 
Rick  Severinghaus 
Ron  Sprinkle 
Tim  Spollen 
Paul  Sutton 
Jeff  Vogel 


Andy  Bowers 
Nikhil  Dave 
Larry  Dworkin 
Jerry  Forbes 
Larry  Goldberg 
Gene  Layman 
Albert  Legaspi 
Tom  Mullins 
Gary  Parker 
John  Roberts 
Fred  Smith 
Ed  Sowell 
Bill  Sudnikovich 
Ken  Sullivan 
Gary  Waag 


